[CPyUG:110366] 关于Pythonic哲学的一点思考

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[CPyUG:110366] 关于Pythonic哲学的一点思考

Bugzilla from xrfang@gmail.com
和Z大妈在OBP上有一些关于《蟒样Web应用开发》的思路的讨论,我觉得蛮有意思的,贴到这里来一起讨论讨论。首先是下面这段:

2009/11/24 xrfang <[hidden email]>:
> 对于"简化系统开发工作量、长期维护"这2点我不同意Z大妈的看法,我是Agile的追随者,我喜欢scrum和Dave Thomas的
> Pragmatic Programmer这本书。我相信:

> 1) 持续的Refactoring是非常必要的

但是敏捷世界也同意:"重构是必要的浪费"
> 2)如无必要,勿增实体

每一个种应用冲突问题,都可以通过增加一个中间层,解决;
所以,长期运维时,最频率的就是这种决策...

> 3) 对质量的追求最终会带来项目进度上的巨大收益

但是,多数团队无法获得高层的耐心,等待质量因素的积累发韧时...

> 对于webpy大型应用是否能够适应性能和扩展性要求,这点我不知道,也是我想学习的。另外,我对Z大妈说的2点以及上面"侦探小说"的比喻表示部分赞

这点不用怀疑, Reddit 曾经用的就是 web.py

> 同,毕竟项目管理和技术观点千差万别,webpy不是普适性的。有大量的人就是喜欢Django(远超webpy),甚至是Zope3,而我认为这两者
> 是不符合Pythonic的哲学的 -- 按这论坛的观点--我很同意--就是"大道至简"。

大道至简 ~ 对象是用户或是开发人员,大道本身是否是由简单组件构成的,并没有要求;
象M$ 系统,将超复杂的问题,封闭在 dll 之后,给开发人员和用户一个简洁的界面,这也是道行...

当然 Pythonic 追求的是简单凝练, 提炼问题域的通用组件,简单靠谱的复用下去,合理的堆积而不会出问题,
就是出问题也可以简单的处理掉,,,

Zope3 通过不断的PK掉自个儿的整个结构 ,来探索复杂和简单的平衡;
Django 通过坚持自个儿的思想,绝对不轻易加入任何叫好的特性,来保持自个儿内外接口的简单稳定;
PyLons/Turbogeas 通过最宽容的 mixin 结构,确保自身的简单>...

都是非常好的解决之道;

CherryPy 和 web.py 则是坚持只提供最常用的核心 web 应用能力,从而将注意力收敛到web 应用的最核心非可用性领域,
从而逐渐成为各种框架的基础框架....

这也是很禅的解决之道, 而且是个趋势 ~ 专用的永远比通用的要稳定;
但是,现实中的项目开发,真的是在拼速度而不是质量哪!
所以,谁提供最多的模块的同时,可以兼顾给出一定的质量和性能,谁就是明星框架...

- 隐藏被引用文字 -
- 显示引用的文字 -
--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110368] Re: 关于Pythonic哲学的一点思考

Bugzilla from xrfang@gmail.com
我同意Pythonic==大道至简的观点。而我对“大道至简”的理解是老子说的:为学日益,为道日损,损之又损,以至于无为。

我无意贬低任何框架。我相信Django和Zope3都是非常优秀的“框架”。可是大家注意了,“框架”这个词其实已经限定了Django之流的定位,
它是什么?它不是“道”,而是“术”。Z大妈说的“象M$ 系统,将超复杂的问题,封闭在 dll 之后,给开发人员和用户一个简洁的界面,这也是道
行... ”这句,是引发我写这篇回帖的两大主因之一。我认为,道是简单的,永恒的,术是复杂的、快速变化的。将超复杂的问题封闭在dll里面这种行为
不是学术(道),而是工程(术)。比如python语言很简练,但python编译器却非常的复杂。这就是一个道、一个术。

说到这里,有人会不服气了,说是不是有意把webpy捧太高了?它能说是”道“吗?确实,它不是道,但我认为它可以当的起”道器合一“这句考语。它
是”损之又损,几近于大道“矣。WEB的道在哪里?我认为是HTTP协议(或可附加更底层的TCP/IP协议);编程的道在哪里?是面向对象、面向契
约、函数式编程、MVC(或用Django术语称为MTV)等等这些”paradigm“(见仁见智,自己选了)。而框架是什么?是根据这些“道”发展
出来的“偷懒”的方法。一般来说,99.9%的框架使用者对框架的理解都不及框架的原设计者,其原因,一则可能是水平问题,但更重要的是,框架的创建者
是“七十从心所欲而不逾矩”,就是说,对道的理解已经到了非常高的水平,以至于写出来的框架能够随心所欲,使用的时候能够“人剑合一”。。。(此处省略
500字)

那么说了半天,我反对框架的第二个原因是什么?何为大道至简?“简”是偷懒吗?不对!简是对“道”的状态的描述,说的是“万变不离其宗”,(在某一领域
内)任何事物都受到(该领域内“道”的约束和影响。一个巨复杂的框架,它是永远不可能成为“道”的!也永远不会是Pythonic的(如果
Pythonic==大道至简)。

我1996年毕业就从程序员做起,杂七杂八用了很多语言、“框架”,真的是感觉到完全没必要再多一个框架了。这个世界是自由的,框架的诞生是由框架主自
由意志的决定。可是,旁人有没有必要去跟风?这是一个严重的问题。OK你说你拿Django当饭吃,我没话说,但是,任何人都不能说Django就比
Spring+Hibernate+Struts好在哪里?也没有一个RoR的拥趸能够说服一个Django的拥趸放弃之。

我Ruby相当熟悉,本来不想学Python的,一个偶尔机会,学了一会,不巧就会了。一会,就去查查能否用Python写web程序,不巧就找到了
webpy(在此过程中#python有很多大师级python用户介绍我看看Pylons和web2py,说webpy不好云云),不巧又学会了。于
是我心血来潮就喜欢上它了。

一言以蔽之,webpy让我看到了道(虽然它自己不是道),而其他的框架则是自创了一套东西,告诉我,这个就是“道”。用webpy主页上一个用户的评
论来结束我的喋喋不休:

"Django lets you write web apps in Django. TurboGears lets you write
web apps in TurboGears. Web.py lets you write web apps in Python."
- Adam Atlas
--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110376] Re: 关于Pythonic哲学的一点思考

Zoom.Quiet
2009/11/25 xrfang <[hidden email]>:
> 我同意Pythonic==大道至简的观点。而我对“大道至简”的理解是老子说的:为学日益,为道日损,损之又损,以至于无为。
>
很高兴有人对 Pythonic 的定义进行校真哈!

...
> 不是学术(道),而是工程(术)。比如python语言很简练,但python编译器却非常的复杂。这就是一个道、一个术。
嗯嗯嗯,这个逻辑很通...

...
> 约、函数式编程、MVC(或用Django术语称为MTV)等等这些”paradigm“(见仁见智,自己选了)。而框架是什么?是根据这些“道”发展
> 出来的“偷懒”的方法。一般来说,99.9%的框架使用者对框架的理解都不及框架的原设计者,其原因,一则可能是水平问题,但更重要的是,框架的创建者
> 是“七十从心所欲而不逾矩”,就是说,对道的理解已经到了非常高的水平,以至于写出来的框架能够随心所欲,使用的时候能够“人剑合一”

这里我有点体会:
- 外衍越小,内涵越大!
  - 好比数字0 和 3.1415926....
  - 0 的外衍极有限,但是可以拿来作N多事儿和比喻以及代言
  - 而 π 外衍极大,但是其含义和意义,以及作用就唯一了
对于框架,所有框架,都是创造者在过住经验中总结出来的决策集凝结成的一种禁止随心所欲的围墙;
web.py/CherryPy 一樣有限制,只是限制少到感觉不出来;
导致的结果是:
- 限制非常少的框架,意味着最丰富的外衍,开发者可以想作什么就作什么;从而在实际应用开发中,要面对一切决策:
    ? 用session,怎么实现/借用/引入?简单的?面向文件的?JSON的?DB的?
    ? 用ORM:怎么实现/借用/引入?简单的?面向MySQL only的?主流DB的?
    ...
- 限制非常多的框架(当然同时也得对应的给出相应的丰富内置功能),开发者必须理解框架的意识,在框架的意识允许领域中进行创造;
    但是,不用再面对一切决策了;
    框架已經事先作好了各种层面的决策,而且通过这些预设的决策,将整个基于自个儿开发出来的应用可以照顾的很好;
    开发者,反而可以集中精力用对象/过程/算法,在限制的框架中,实现功能,完成需求;
    反而,容易快速创造出想作的应用来...

这也好比男女交往没有什么限制的现在,大家都有N多选择,反而无从选择,导致离婚不育比较的升高;
反而在古代,重重限制中,有那么多美好的爱情故事和诗歌出现 ;-)
...
> 我1996年毕业就从程序员做起,杂七杂八用了很多语言、“框架”,真的是感觉到完全没必要再多一个框架了。这个世界是自由的,框架的诞生是由框架主自
> 由意志的决定。可是,旁人有没有必要去跟风?这是一个严重的问题。OK你说你拿Django当饭吃,我没话说,但是,任何人都不能说Django就比

是否跟风,和意志无关,多数是从成本考虑的:
- 一个契合需求,有同类成功案例和代码借鉴的框架,必须给工程的高速交付带来极大的保证
- 同时,也是对不同社区的信心不同的决择而已

>
> 我Ruby相当熟悉,本来不想学Python的,一个偶尔机会,学了一会,不巧就会了。一会,就去查查能否用Python写web程序,不巧就找到了
> webpy(在此过程中#python有很多大师级python用户介绍我看看Pylons和web2py,说webpy不好云云),不巧又学会了。于
> 是我心血来潮就喜欢上它了。

咔咔咔,原来如比,祝贺你被 Pythonic 了 ;-)

> "Django lets you write web apps in Django. TurboGears lets you write
> web apps in TurboGears. Web.py lets you write web apps in Python."
> - Adam Atlas

非常非常精妙的解释,这的确是用 web.py/CherryPy 的感觉;
但是,好比建水利工程,以前中国真的是用人堆出来的,现在是一堆专用机械快速批量建造了;
- 用 web.py 或是纯Python 我们一样可以创建各种 web 应用,但是,要堆大量的时间和精力来原创出所有功能来应对实现过程中遇见的需求;
- 用其它有很 术 的框架,却是在忍受了限制的同时,可以复用社区积累出来的大量稳定的模块来直接支持相关常见需求;

那种爽,的确是个人体验,
不过,就公司行为,一定是从会计角度进行重点分析的 ;-(



--
http://zoomquiet.org 人生苦短? Pythonic!
金山常年招聘Py/C++人才! http://bit.ly/UoTV 简历直投俺就成;-)

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110382] Re: 关于Pythonic哲学的一点思考

Bugzilla from xrfang@gmail.com
嗯,我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度,因为他们已经摸透了诸多框架
的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下,选定一个框架非常有必要,因为这样
可以简化沟通、简化工作。当然,这里的选择就是哪个框架成熟、用的人多(那么就更容易招聘到好的工程师)。

可是,我对建筑(水利)和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目,工程师和建筑师是截然不同的角色,虽然建筑师也是要
懂力学的。IT项目虽然也"应该"这样,但现实中却...... 另外,我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
SQLAlchemy,可以用于webpy,也可以用于很多其他框架。SQLAlchemy是一个库,而不是一个框架。思考一下"库"对外界的接口、框
架对外界的接口,我们会发现,形形色色的库,他们的接口非常类似,不外乎就是函数、类、变量...更底层的说,类也没有了,就是一个"代码快的入口
(entry point)"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西,多少年了,只有增加,也没有什么大的变
化....工程学上的"向下兼容"在这里体现得非常好。而如今,框架漫天飞的年代,大家看看,能不能学了一个Django以后,不用学
TurboGears了,只要一本TG参考手册就开始写TG程序?

On 11月26日, 上午12时27分, "Zoom.Quiet" <[hidden email]> wrote:

> 2009/11/25 xrfang <[hidden email]>:> 我同意Pythonic==大道至简的观点。而我对"大道至简"的理解是老子说的:为学日益,为道日损,损之又损,以至于无为。
>
> 很高兴有人对 Pythonic 的定义进行校真哈!
>
> ...> 不是学术(道),而是工程(术)。比如python语言很简练,但python编译器却非常的复杂。这就是一个道、一个术。
>
> 嗯嗯嗯,这个逻辑很通...
>
> ...
>
> > 约、函数式编程、MVC(或用Django术语称为MTV)等等这些"paradigm"(见仁见智,自己选了)。而框架是什么?是根据这些"道"发展
> > 出来的"偷懒"的方法。一般来说,99.9%的框架使用者对框架的理解都不及框架的原设计者,其原因,一则可能是水平问题,但更重要的是,框架的创建者
> > 是"七十从心所欲而不逾矩",就是说,对道的理解已经到了非常高的水平,以至于写出来的框架能够随心所欲,使用的时候能够"人剑合一"
>
> 这里我有点体会:
> - 外衍越小,内涵越大!
>   - 好比数字0 和 3.1415926....
>   - 0 的外衍极有限,但是可以拿来作N多事儿和比喻以及代言
>   - 而 π 外衍极大,但是其含义和意义,以及作用就唯一了
> 对于框架,所有框架,都是创造者在过住经验中总结出来的决策集凝结成的一种禁止随心所欲的围墙;
> web.py/CherryPy 一樣有限制,只是限制少到感觉不出来;
> 导致的结果是:
> - 限制非常少的框架,意味着最丰富的外衍,开发者可以想作什么就作什么;从而在实际应用开发中,要面对一切决策:
>     ? 用session,怎么实现/借用/引入?简单的?面向文件的?JSON的?DB的?
>     ? 用ORM:怎么实现/借用/引入?简单的?面向MySQL only的?主流DB的?
>     ...
> - 限制非常多的框架(当然同时也得对应的给出相应的丰富内置功能),开发者必须理解框架的意识,在框架的意识允许领域中进行创造;
>     但是,不用再面对一切决策了;
>     框架已經事先作好了各种层面的决策,而且通过这些预设的决策,将整个基于自个儿开发出来的应用可以照顾的很好;
>     开发者,反而可以集中精力用对象/过程/算法,在限制的框架中,实现功能,完成需求;
>     反而,容易快速创造出想作的应用来...
>
> 这也好比男女交往没有什么限制的现在,大家都有N多选择,反而无从选择,导致离婚不育比较的升高;
> 反而在古代,重重限制中,有那么多美好的爱情故事和诗歌出现 ;-)
> ...
>
> > 我1996年毕业就从程序员做起,杂七杂八用了很多语言、"框架",真的是感觉到完全没必要再多一个框架了。这个世界是自由的,框架的诞生是由框架主自
> > 由意志的决定。可是,旁人有没有必要去跟风?这是一个严重的问题。OK你说你拿Django当饭吃,我没话说,但是,任何人都不能说Django就比
>
> 是否跟风,和意志无关,多数是从成本考虑的:
> - 一个契合需求,有同类成功案例和代码借鉴的框架,必须给工程的高速交付带来极大的保证
> - 同时,也是对不同社区的信心不同的决择而已
>
>
>
> > 我Ruby相当熟悉,本来不想学Python的,一个偶尔机会,学了一会,不巧就会了。一会,就去查查能否用Python写web程序,不巧就找到了
> > webpy(在此过程中#python有很多大师级python用户介绍我看看Pylons和web2py,说webpy不好云云),不巧又学会了。于
> > 是我心血来潮就喜欢上它了。
>
> 咔咔咔,原来如比,祝贺你被 Pythonic 了 ;-)
>
> > "Django lets you write web apps in Django. TurboGears lets you write
> > web apps in TurboGears. Web.py lets you write web apps in Python."
> > - Adam Atlas
>
> 非常非常精妙的解释,这的确是用 web.py/CherryPy 的感觉;
> 但是,好比建水利工程,以前中国真的是用人堆出来的,现在是一堆专用机械快速批量建造了;
> - 用 web.py 或是纯Python 我们一样可以创建各种 web 应用,但是,要堆大量的时间和精力来原创出所有功能来应对实现过程中遇见的需求;
> - 用其它有很 术 的框架,却是在忍受了限制的同时,可以复用社区积累出来的大量稳定的模块来直接支持相关常见需求;
>
> 那种爽,的确是个人体验,
> 不过,就公司行为,一定是从会计角度进行重点分析的 ;-(
>
> --http://zoomquiet.org人生苦短? Pythonic!
> 金山常年招聘Py/C++人才!http://bit.ly/UoTV简历直投俺就成;-)
--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110407] Re: 关于Pythonic哲学的一点思考

limodou
2009/11/26 xrfang <[hidden email]>:

> 嗯,我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度,因为他们已经摸透了诸多框架
> 的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下,选定一个框架非常有必要,因为这样
> 可以简化沟通、简化工作。当然,这里的选择就是哪个框架成熟、用的人多(那么就更容易招聘到好的工程师)。
>
> 可是,我对建筑(水利)和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目,工程师和建筑师是截然不同的角色,虽然建筑师也是要
> 懂力学的。IT项目虽然也"应该"这样,但现实中却...... 另外,我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
> SQLAlchemy,可以用于webpy,也可以用于很多其他框架。SQLAlchemy是一个库,而不是一个框架。思考一下"库"对外界的接口、框
> 架对外界的接口,我们会发现,形形色色的库,他们的接口非常类似,不外乎就是函数、类、变量...更底层的说,类也没有了,就是一个"代码快的入口
> (entry point)"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西,多少年了,只有增加,也没有什么大的变
> 化....工程学上的"向下兼容"在这里体现得非常好。而如今,框架漫天飞的年代,大家看看,能不能学了一个Django以后,不用学
> TurboGears了,只要一本TG参考手册就开始写TG程序?
>

曾经在了解一个新的叫SpringPython的框架 http://springpython.webfactional.com/
这个完全是spring的python版,很有意思,就是今年才出来的,报道的比较少。其中它有着和spring一样的Ioc的概念和依赖式注册等。其实这些东西在许多框架中都有。后来又顺着找到了Martin
Flower的一篇博文 http://martinfowler.com/bliki/InversionOfControl.html
主要是讲Ioc的,其中他谈到:

Inversion of Control is a key part of what makes a framework different
to a library. A library is essentially a set of functions that you can
call, these days usually organized into classes. Each call does some
work and returns control to the client.

A framework embodies some abstract design, with more behavior built
in. In order to use it you need to insert your behavior into various
places in the framework either by subclassing or by plugging in your
own classes. The framework's code then calls your code at these
points.

从上面的理解可以看到,框架与库之前还是有区别的。使用库,完全在你的控制之下,而使用框架,基本上你在它的控制之下。框架会提供更多的环境和嵌入更多的功能。

至于你是想利用库还是利用框架是用户自已的事,但是框架正如zoom.quiet所说的,它有着自已的限定,一方面提供了更为方便的使用方式,另一方面要求用户按照框架的“哲学”来使用,来编程,有自已的领域。如果你只是希望使用一个web开发的库,不希望局限于某个框架没问题,现在有许多这样的东西,象:werkzeug就是一个,当然还有其它的。有兴趣你可以研究一下。

--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110413] Re: 关于Pythonic哲学的一点思考

刘鑫
In reply to this post by Bugzilla from xrfang@gmail.com


2009/11/26 xrfang <[hidden email]>
嗯,我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度,因为他们已经摸透了诸多框架
的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下,选定一个框架非常有必要,因为这样
可以简化沟通、简化工作。当然,这里的选择就是哪个框架成熟、用的人多(那么就更容易招聘到好的工程师)。

可是,我对建筑(水利)和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目,工程师和建筑师是截然不同的角色,虽然建筑师也是要
懂力学的。IT项目虽然也"应该"这样,但现实中却...... 另外,我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
SQLAlchemy,可以用于webpy,也可以用于很多其他框架。SQLAlchemy是一个库,而不是一个框架。思考一下"库"对外界的接口、框
架对外界的接口,我们会发现,形形色色的库,他们的接口非常类似,不外乎就是函数、类、变量...更底层的说,类也没有了,就是一个"代码快的入口
(entry point)"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西,多少年了,只有增加,也没有什么大的变
化....工程学上的"向下兼容"在这里体现得非常好。而如今,框架漫天飞的年代,大家看看,能不能学了一个Django以后,不用学
TurboGears了,只要一本TG参考手册就开始写TG程序?

每次看到有人指点江山我就想含笑而过……

--
每一个成功都是不可复制的。
……

劉鑫
March.Liu

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110470] Re: 关于Pythonic哲学的一点思考

Chen GUO-2
有些“被”规范的东西吧,有它的意义,就好象,走路,什么路都能走,但是开车,只能在平坦的路上走,火车呢,还的要轨道。确实,走路,不受限制,或者说,限制最少,火车确实被限制了,想多转个弯都得坏事,但是从北京走到西藏试试看?还得火车
框架设计者和使用者,一个是定规矩的,一个是守规矩的,但是要说设计者就怎么怎么理解的深刻,我看也未必

On 11/26/09, 刘鑫 <[hidden email]> wrote:

> 2009/11/26 xrfang <[hidden email]>
>
>> 嗯,我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度,因为他们已经摸透了诸多框架
>> 的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下,选定一个框架非常有必要,因为这样
>> 可以简化沟通、简化工作。当然,这里的选择就是哪个框架成熟、用的人多(那么就更容易招聘到好的工程师)。
>>
>> 可是,我对建筑(水利)和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目,工程师和建筑师是截然不同的角色,虽然建筑师也是要
>> 懂力学的。IT项目虽然也"应该"这样,但现实中却...... 另外,我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
>> SQLAlchemy,可以用于webpy,也可以用于很多其他框架。SQLAlchemy是一个库,而不是一个框架。思考一下"库"对外界的接口、框
>> 架对外界的接口,我们会发现,形形色色的库,他们的接口非常类似,不外乎就是函数、类、变量...更底层的说,类也没有了,就是一个"代码快的入口
>> (entry point)"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西,多少年了,只有增加,也没有什么大的变
>> 化....工程学上的"向下兼容"在这里体现得非常好。而如今,框架漫天飞的年代,大家看看,能不能学了一个Django以后,不用学
>> TurboGears了,只要一本TG参考手册就开始写TG程序?
>>
>
> 每次看到有人指点江山我就想含笑而过……
>
> --
> 每一个成功都是不可复制的。
> ……
>
> 劉鑫
> March.Liu
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110501] Re: 关于Pythonic哲学的一点思考

ubunoon-2
火车的native速度与走路的native速度不是一个等级,自然也就屏蔽了这个规矩带来的不利影响。关于框架,有很多讨论,我在第一次入门MFC的时候,就看到侯先生对于框架的一些摘录与说法,框架,必然限制你进行一系列的扩展或者只能够在某个特殊的地方进行特殊的需求操作,而没有SDK之类直接使用库的快捷性,但框架,也给用户带来更多已经设计和实现的细节处理,从而使得用户摆脱对具体操作的考虑,而集中精神去考虑框架范围下,程序所需要实现的功能。

火车需要铺设轨道,走路,则只需要一条道路就可以,这之间的成本是不一样的,我比较接受MFC中关于学习的一个看法,学些框架,前期的投入是巨大的,曲线是很斗的,一旦学会,游刃有余之时,实现内容便不毫不费事,而学习SDK之类的库,前期学习会非常容易,但是创建成本太高。


2009/11/26 Chen GUO <[hidden email]>
有些“被”规范的东西吧,有它的意义,就好象,走路,什么路都能走,但是开车,只能在平坦的路上走,火车呢,还的要轨道。确实,走路,不受限制,或者说,限制最少,火车确实被限制了,想多转个弯都得坏事,但是从北京走到西藏试试看?还得火车
框架设计者和使用者,一个是定规矩的,一个是守规矩的,但是要说设计者就怎么怎么理解的深刻,我看也未必

On 11/26/09, 刘鑫 <[hidden email]> wrote:
> 2009/11/26 xrfang <[hidden email]>
>
>> 嗯,我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度,因为他们已经摸透了诸多框架
>> 的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下,选定一个框架非常有必要,因为这样
>> 可以简化沟通、简化工作。当然,这里的选择就是哪个框架成熟、用的人多(那么就更容易招聘到好的工程师)。
>>
>> 可是,我对建筑(水利)和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目,工程师和建筑师是截然不同的角色,虽然建筑师也是要
>> 懂力学的。IT项目虽然也"应该"这样,但现实中却...... 另外,我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
>> SQLAlchemy,可以用于webpy,也可以用于很多其他框架。SQLAlchemy是一个库,而不是一个框架。思考一下"库"对外界的接口、框
>> 架对外界的接口,我们会发现,形形色色的库,他们的接口非常类似,不外乎就是函数、类、变量...更底层的说,类也没有了,就是一个"代码快的入口
>> (entry point)"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西,多少年了,只有增加,也没有什么大的变
>> 化....工程学上的"向下兼容"在这里体现得非常好。而如今,框架漫天飞的年代,大家看看,能不能学了一个Django以后,不用学
>> TurboGears了,只要一本TG参考手册就开始写TG程序?
>>
>
> 每次看到有人指点江山我就想含笑而过……
>
> --
> 每一个成功都是不可复制的。
> ……
>
> 劉鑫
> March.Liu
>
> >
>





--
To be pythoner
My blog: http://www.cnblogs.com/ubunoon/


--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110506] Re: 关于Pythonic哲学的一点思考

eric-347
真正的哲学最后都是亦阴亦阳的,
对于框架来说,从哲学的角度看应该是:
在需要框架的基础上又不需要框架,或者在不需要框架的基础上又需要框架
两者是并存的,是互根的,是一体的,是根本上无差别的

2009/11/26 ubunoon <[hidden email]>
火车的native速度与走路的native速度不是一个等级,自然也就屏蔽了这个规矩带来的不利影响。关于框架,有很多讨论,我在第一次入门MFC的时候,就看到侯先生对于框架的一些摘录与说法,框架,必然限制你进行一系列的扩展或者只能够在某个特殊的地方进行特殊的需求操作,而没有SDK之类直接使用库的快捷性,但框架,也给用户带来更多已经设计和实现的细节处理,从而使得用户摆脱对具体操作的考虑,而集中精神去考虑框架范围下,程序所需要实现的功能。

火车需要铺设轨道,走路,则只需要一条道路就可以,这之间的成本是不一样的,我比较接受MFC中关于学习的一个看法,学些框架,前期的投入是巨大的,曲线是很斗的,一旦学会,游刃有余之时,实现内容便不毫不费事,而学习SDK之类的库,前期学习会非常容易,但是创建成本太高。


2009/11/26 Chen GUO <[hidden email]>

有些“被”规范的东西吧,有它的意义,就好象,走路,什么路都能走,但是开车,只能在平坦的路上走,火车呢,还的要轨道。确实,走路,不受限制,或者说,限制最少,火车确实被限制了,想多转个弯都得坏事,但是从北京走到西藏试试看?还得火车
框架设计者和使用者,一个是定规矩的,一个是守规矩的,但是要说设计者就怎么怎么理解的深刻,我看也未必

On 11/26/09, 刘鑫 <[hidden email]> wrote:
> 2009/11/26 xrfang <[hidden email]>
>
>> 嗯,我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度,因为他们已经摸透了诸多框架
>> 的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下,选定一个框架非常有必要,因为这样
>> 可以简化沟通、简化工作。当然,这里的选择就是哪个框架成熟、用的人多(那么就更容易招聘到好的工程师)。
>>
>> 可是,我对建筑(水利)和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目,工程师和建筑师是截然不同的角色,虽然建筑师也是要
>> 懂力学的。IT项目虽然也"应该"这样,但现实中却...... 另外,我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
>> SQLAlchemy,可以用于webpy,也可以用于很多其他框架。SQLAlchemy是一个库,而不是一个框架。思考一下"库"对外界的接口、框
>> 架对外界的接口,我们会发现,形形色色的库,他们的接口非常类似,不外乎就是函数、类、变量...更底层的说,类也没有了,就是一个"代码快的入口
>> (entry point)"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西,多少年了,只有增加,也没有什么大的变
>> 化....工程学上的"向下兼容"在这里体现得非常好。而如今,框架漫天飞的年代,大家看看,能不能学了一个Django以后,不用学
>> TurboGears了,只要一本TG参考手册就开始写TG程序?
>>
>
> 每次看到有人指点江山我就想含笑而过……
>
> --
> 每一个成功都是不可复制的。
> ……
>
> 劉鑫
> March.Liu
>
> >
>





--
To be pythoner
My blog: http://www.cnblogs.com/ubunoon/






--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110507] Re: 关于Pythonic哲学的一点思考

Bugzilla from xrfang@gmail.com
In reply to this post by ubunoon-2
这比喻一半有理。我感觉不妥的地方是拿走路和火车比。应该说是,你手头有一个马达、四个轮子。。。。这些资源,然后和火车比。你的劣势就是一开始要装配
车子,当然,你也可以用别人装配好的发动机总成(例如SQLAlchemy),这样你就可以少装一点东西,不过无论如何都是没有火车来的方便。

但是,有2点考虑:

1)长远来说自己的车子灵活性大性能高,出了问题自己也可以搞定
2)你坐火车的话,你不是乘客,而是列车驾驶员,这样,你要学习怎么开火车,这也是一笔开销。当然对于一个运输公司来说,养一批火车司机比养一批能修小
车的自备车驾驶员是要划算一点的。只是,你能经营的可能只是Django线路,或者TurboGears线路,这对公司没有什么,对个人是个选择。


On 11月26日, 下午4时11分, ubunoon <[hidden email]> wrote:

> 火车的native速度与走路的native速度不是一个等级,自然也就屏蔽了这个规矩带来的不利影响。关于框架,有很多讨论,我在第一次入门MFC的时候,就看到侯先生对于框架的一些摘录与说法,框架,必然限制你进行一系列的扩展或者只能够在某个特殊的地方进行特殊的需求操作,而没有SDK之类直接使用库的快捷性,但框架,也给用户带来更多已经设计和实现的细节处理,从而使得用户摆脱对具体操作的考虑,而集中精神去考虑框架范围下,程序所需要实现的功能。
>
> 火车需要铺设轨道,走路,则只需要一条道路就可以,这之间的成本是不一样的,我比较接受MFC中关于学习的一个看法,学些框架,前期的投入是巨大的,曲线是很斗的,一旦学会,游刃有余之时,实现内容便不毫不费事,而学习SDK之类的库,前期学习会非常容易,但是创建成本太高。
>
> 2009/11/26 Chen GUO <[hidden email]>
>
>
>
>
>
> > 有些“被”规范的东西吧,有它的意义,就好象,走路,什么路都能走,但是开车,只能在平坦的路上走,火车呢,还的要轨道。确实,走路,不受限制,或者说,限制最少,火车确实被限制了,想多转个弯都得坏事,但是从北京走到西藏试试看?还得火车
> > 框架设计者和使用者,一个是定规矩的,一个是守规矩的,但是要说设计者就怎么怎么理解的深刻,我看也未必
>
> > On 11/26/09, 刘鑫 <[hidden email]> wrote:
> > > 2009/11/26 xrfang <[hidden email]>
>
> > >> 嗯,我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度,因为他们已经摸透了诸多框架
> > >> 的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下,选定一个框架非常有必要,因为这样
> > >> 可以简化沟通、简化工作。当然,这里的选择就是哪个框架成熟、用的人多(那么就更容易招聘到好的工程师)。
>
> > >> 可是,我对建筑(水利)和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目,工程师和建筑师是截然不同的角色,虽然建筑师也是要
> > >> 懂力学的。IT项目虽然也"应该"这样,但现实中却...... 另外,我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
> > >> SQLAlchemy,可以用于webpy,也可以用于很多其他框架。SQLAlchemy是一个库,而不是一个框架。思考一下"库"对外界的接口、框
> > >> 架对外界的接口,我们会发现,形形色色的库,他们的接口非常类似,不外乎就是函数、类、变量...更底层的说,类也没有了,就是一个"代码快的入口
> > >> (entry point)"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西,多少年了,只有增加,也没有什么大的变
> > >> 化....工程学上的"向下兼容"在这里体现得非常好。而如今,框架漫天飞的年代,大家看看,能不能学了一个Django以后,不用学
> > >> TurboGears了,只要一本TG参考手册就开始写TG程序?
>
> > > 每次看到有人指点江山我就想含笑而过……
>
> > > --
> > > 每一个成功都是不可复制的。
> > > ……
>
> > > 劉鑫
> > > March.Liu
>
> --
> To be pythoner
> My blog:http://www.cnblogs.com/ubunoon/
--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110509] Re: 关于Pythonic哲学的一点思考

Bugzilla from xrfang@gmail.com
In reply to this post by ubunoon-2
创建成本是有积累的,即使用webpy也会随着项目的积累缓缓的下降的。我和Z大妈在OBP讨论这个问题的时候一开始就说了提议“蟒样Web开发”这书
的目标读者,就是熟练的但有不拘泥于底层的开发者。如果有人对Django什么的用的很熟,他完全没有必要去换成webpy或者web2py什么的,只
要继续用就是了。我对框架的意见其实就是一个学习(和维持)的成本。从某一方面来说,我不反对任何框架。我只是说如果你没有学过Django/
TG/...,现在想选个python“框架”,不妨学习最“大道至简”的框架。

On 11月26日, 下午4时11分, ubunoon <[hidden email]> wrote:

> 火车的native速度与走路的native速度不是一个等级,自然也就屏蔽了这个规矩带来的不利影响。关于框架,有很多讨论,我在第一次入门MFC的时候,就看到侯先生对于框架的一些摘录与说法,框架,必然限制你进行一系列的扩展或者只能够在某个特殊的地方进行特殊的需求操作,而没有SDK之类直接使用库的快捷性,但框架,也给用户带来更多已经设计和实现的细节处理,从而使得用户摆脱对具体操作的考虑,而集中精神去考虑框架范围下,程序所需要实现的功能。
>
> 火车需要铺设轨道,走路,则只需要一条道路就可以,这之间的成本是不一样的,我比较接受MFC中关于学习的一个看法,学些框架,前期的投入是巨大的,曲线是很斗的,一旦学会,游刃有余之时,实现内容便不毫不费事,而学习SDK之类的库,前期学习会非常容易,但是创建成本太高。
>
> 2009/11/26 Chen GUO <[hidden email]>
>
>
>
>
>
> > 有些“被”规范的东西吧,有它的意义,就好象,走路,什么路都能走,但是开车,只能在平坦的路上走,火车呢,还的要轨道。确实,走路,不受限制,或者说,限制最少,火车确实被限制了,想多转个弯都得坏事,但是从北京走到西藏试试看?还得火车
> > 框架设计者和使用者,一个是定规矩的,一个是守规矩的,但是要说设计者就怎么怎么理解的深刻,我看也未必
>
> > On 11/26/09, 刘鑫 <[hidden email]> wrote:
> > > 2009/11/26 xrfang <[hidden email]>
>
> > >> 嗯,我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度,因为他们已经摸透了诸多框架
> > >> 的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下,选定一个框架非常有必要,因为这样
> > >> 可以简化沟通、简化工作。当然,这里的选择就是哪个框架成熟、用的人多(那么就更容易招聘到好的工程师)。
>
> > >> 可是,我对建筑(水利)和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目,工程师和建筑师是截然不同的角色,虽然建筑师也是要
> > >> 懂力学的。IT项目虽然也"应该"这样,但现实中却...... 另外,我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
> > >> SQLAlchemy,可以用于webpy,也可以用于很多其他框架。SQLAlchemy是一个库,而不是一个框架。思考一下"库"对外界的接口、框
> > >> 架对外界的接口,我们会发现,形形色色的库,他们的接口非常类似,不外乎就是函数、类、变量...更底层的说,类也没有了,就是一个"代码快的入口
> > >> (entry point)"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西,多少年了,只有增加,也没有什么大的变
> > >> 化....工程学上的"向下兼容"在这里体现得非常好。而如今,框架漫天飞的年代,大家看看,能不能学了一个Django以后,不用学
> > >> TurboGears了,只要一本TG参考手册就开始写TG程序?
>
> > > 每次看到有人指点江山我就想含笑而过……
>
> > > --
> > > 每一个成功都是不可复制的。
> > > ……
>
> > > 劉鑫
> > > March.Liu
>
> --
> To be pythoner
> My blog:http://www.cnblogs.com/ubunoon/
--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110546] Re: 关于Pythonic哲学的一点思考

Zoom.Quiet
In reply to this post by Bugzilla from xrfang@gmail.com
2009/11/26 xrfang <[hidden email]>:
> 这比喻一半有理。我感觉不妥的地方是拿走路和火车比。应该说是,你手头有一个马达、四个轮子。。。。这些资源,然后和火车比。你的劣势就是一开始要装配
> 车子,当然,你也可以用别人装配好的发动机总成(例如SQLAlchemy),这样你就可以少装一点东西,不过无论如何都是没有火车来的方便。
>
> 但是,有2点考虑:
>
> 1)长远来说自己的车子灵活性大性能高,出了问题自己也可以搞定
> 2)你坐火车的话,你不是乘客,而是列车驾驶员,这样,你要学习怎么开火车,这也是一笔开销。当然对于一个运输公司来说,养一批火车司机比养一批能修小
> 车的自备车驾驶员是要划算一点的。只是,你能经营的可能只是Django线路,或者TurboGears线路,这对公司没有什么,对个人是个选择。
>

今天部门的内部知识分享活动中,刘鑫指出了过往对框架和库对比的问题:
- 混淆了运行期和开发期的不同对象, 进行了不必要的对比
- 库其实都是开发期的代码/dll ... 是不开发者直接面对的
- 框架其实重点是照顾运行期内存对象的,是更加接近用户的
所以,框架多是包装了基些领域知识/经验,形成了内建规范/限制,来确保运行期的对象安定;也从而从整体上降低了应用的开发成本;'

而 web.py 这种更加象库的极轻框架,其实是开发者一伙儿的,
在提供了基础运行期限制后,尽可能的开放开发期限制;
同时,也就没有包含有针对性的领域经验内建,这方面完全丢给了开发者自行决策;
那么,就好比 MFC 和 Notes 的对比了, MFC 一樣可以开发出 Notes 的 clone 来,
但是无法形成基于 Notes 开发的规模效应了,
因为 Notes 包含了 IBM 几十年的领域运营经验...

>
> On 11月26日, 下午4时11分, ubunoon <[hidden email]> wrote:
>> 火车的native速度与走路的native速度不是一个等级,自然也就屏蔽了这个规矩带来的不利影响。关于框架,有很多讨论,我在第一次入门MFC的时候,就看到侯先生对于框架的一些摘录与说法,框架,必然限制你进行一系列的扩展或者只能够在某个特殊的地方进行特殊的需求操作,而没有SDK之类直接使用库的快捷性,但框架,也给用户带来更多已经设计和实现的细节处理,从而使得用户摆脱对具体操作的考虑,而集中精神去考虑框架范围下,程序所需要实现的功能。
>>
>> 火车需要铺设轨道,走路,则只需要一条道路就可以,这之间的成本是不一样的,我比较接受MFC中关于学习的一个看法,学些框架,前期的投入是巨大的,曲线是很斗的,一旦学会,游刃有余之时,实现内容便不毫不费事,而学习SDK之类的库,前期学习会非常容易,但是创建成本太高。
>>
>> 2009/11/26 Chen GUO <[hidden email]>
>>
>>
>>
>>
>>
>> > 有些“被”规范的东西吧,有它的意义,就好象,走路,什么路都能走,但是开车,只能在平坦的路上走,火车呢,还的要轨道。确实,走路,不受限制,或者说,限制最少,火车确实被限制了,想多转个弯都得坏事,但是从北京走到西藏试试看?还得火车
>> > 框架设计者和使用者,一个是定规矩的,一个是守规矩的,但是要说设计者就怎么怎么理解的深刻,我看也未必
>>
>> > On 11/26/09, 刘鑫 <[hidden email]> wrote:
>> > > 2009/11/26 xrfang <[hidden email]>
>>
>> > >> 嗯,我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度,因为他们已经摸透了诸多框架
>> > >> 的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下,选定一个框架非常有必要,因为这样
>> > >> 可以简化沟通、简化工作。当然,这里的选择就是哪个框架成熟、用的人多(那么就更容易招聘到好的工程师)。
>>
>> > >> 可是,我对建筑(水利)和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目,工程师和建筑师是截然不同的角色,虽然建筑师也是要
>> > >> 懂力学的。IT项目虽然也"应该"这样,但现实中却...... 另外,我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
>> > >> SQLAlchemy,可以用于webpy,也可以用于很多其他框架。SQLAlchemy是一个库,而不是一个框架。思考一下"库"对外界的接口、框
>> > >> 架对外界的接口,我们会发现,形形色色的库,他们的接口非常类似,不外乎就是函数、类、变量...更底层的说,类也没有了,就是一个"代码快的入口
>> > >> (entry point)"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西,多少年了,只有增加,也没有什么大的变
>> > >> 化....工程学上的"向下兼容"在这里体现得非常好。而如今,框架漫天飞的年代,大家看看,能不能学了一个Django以后,不用学
>> > >> TurboGears了,只要一本TG参考手册就开始写TG程序?
>>
>> > > 每次看到有人指点江山我就想含笑而过……
>>
>> > > --
>> > > 每一个成功都是不可复制的。
>> > > ……
>>
>> > > 劉鑫
>> > > March.Liu
>>

--
http://zoomquiet.org 人生苦短? Pythonic!
金山常年招聘Py/C++人才! http://bit.ly/UoTV 简历直投俺就成;-)

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110549] Re: 关于Pythonic哲学的一点思考

limodou
2009/11/26 Zoom.Quiet <[hidden email]>:

> 2009/11/26 xrfang <[hidden email]>:
>> 这比喻一半有理。我感觉不妥的地方是拿走路和火车比。应该说是,你手头有一个马达、四个轮子。。。。这些资源,然后和火车比。你的劣势就是一开始要装配
>> 车子,当然,你也可以用别人装配好的发动机总成(例如SQLAlchemy),这样你就可以少装一点东西,不过无论如何都是没有火车来的方便。
>>
>> 但是,有2点考虑:
>>
>> 1)长远来说自己的车子灵活性大性能高,出了问题自己也可以搞定
>> 2)你坐火车的话,你不是乘客,而是列车驾驶员,这样,你要学习怎么开火车,这也是一笔开销。当然对于一个运输公司来说,养一批火车司机比养一批能修小
>> 车的自备车驾驶员是要划算一点的。只是,你能经营的可能只是Django线路,或者TurboGears线路,这对公司没有什么,对个人是个选择。
>>
>
> 今天部门的内部知识分享活动中,刘鑫指出了过往对框架和库对比的问题:
> - 混淆了运行期和开发期的不同对象, 进行了不必要的对比
> - 库其实都是开发期的代码/dll ... 是不开发者直接面对的
> - 框架其实重点是照顾运行期内存对象的,是更加接近用户的
> 所以,框架多是包装了基些领域知识/经验,形成了内建规范/限制,来确保运行期的对象安定;也从而从整体上降低了应用的开发成本;'

库与框架都有运行期和开发期的问题。其实我认为Martin
Flower的解释挺不错。框架与库的主要区别我认为是:框架会主动调用你写的东西,而库则是由你来调用的。正如写GUI程序一样,对于事件处理,是由框架来自动调,而不是你控制的。

--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110550] Re: 关于Pythonic哲学的一点思考

诚子
恩恩,说得好。

2009/11/26 limodou <[hidden email]>
2009/11/26 Zoom.Quiet <[hidden email]>:
> 2009/11/26 xrfang <[hidden email]>:
>> 这比喻一半有理。我感觉不妥的地方是拿走路和火车比。应该说是,你手头有一个马达、四个轮子。。。。这些资源,然后和火车比。你的劣势就是一开始要装配
>> 车子,当然,你也可以用别人装配好的发动机总成(例如SQLAlchemy),这样你就可以少装一点东西,不过无论如何都是没有火车来的方便。
>>
>> 但是,有2点考虑:
>>
>> 1)长远来说自己的车子灵活性大性能高,出了问题自己也可以搞定
>> 2)你坐火车的话,你不是乘客,而是列车驾驶员,这样,你要学习怎么开火车,这也是一笔开销。当然对于一个运输公司来说,养一批火车司机比养一批能修小
>> 车的自备车驾驶员是要划算一点的。只是,你能经营的可能只是Django线路,或者TurboGears线路,这对公司没有什么,对个人是个选择。
>>
>
> 今天部门的内部知识分享活动中,刘鑫指出了过往对框架和库对比的问题:
> - 混淆了运行期和开发期的不同对象, 进行了不必要的对比
> - 库其实都是开发期的代码/dll ... 是不开发者直接面对的
> - 框架其实重点是照顾运行期内存对象的,是更加接近用户的
> 所以,框架多是包装了基些领域知识/经验,形成了内建规范/限制,来确保运行期的对象安定;也从而从整体上降低了应用的开发成本;'

库与框架都有运行期和开发期的问题。其实我认为Martin
Flower的解释挺不错。框架与库的主要区别我认为是:框架会主动调用你写的东西,而库则是由你来调用的。正如写GUI程序一样,对于事件处理,是由框架来自动调,而不是你控制的。

--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou





--
my.unix-center.net/~WeiZhicheng

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110667] Re: 关于Pythonic哲学的一点思考

sootoo
In reply to this post by limodou
我认为,好的框架应该是由"模块化的库组装成的。"

在快速开发阶段,可以使用现成的组合工具,在解决性能问题或特殊需求时,开发人员可以方便的替换库。

当然,这种框架设计思想也存在问题:模块耦合度低,会导致性能下降,代码重复等问题。

On 11月26日, 下午6时34分, limodou <[hidden email]> wrote:

> 2009/11/26 Zoom.Quiet <[hidden email]>:
>
>
>
>
>
> > 2009/11/26 xrfang <[hidden email]>:
> >> 这比喻一半有理。我感觉不妥的地方是拿走路和火车比。应该说是,你手头有一个马达、四个轮子。。。。这些资源,然后和火车比。你的劣势就是一开始要装配
> >> 车子,当然,你也可以用别人装配好的发动机总成(例如SQLAlchemy),这样你就可以少装一点东西,不过无论如何都是没有火车来的方便。
>
> >> 但是,有2点考虑:
>
> >> 1)长远来说自己的车子灵活性大性能高,出了问题自己也可以搞定
> >> 2)你坐火车的话,你不是乘客,而是列车驾驶员,这样,你要学习怎么开火车,这也是一笔开销。当然对于一个运输公司来说,养一批火车司机比养一批能修小
> >> 车的自备车驾驶员是要划算一点的。只是,你能经营的可能只是Django线路,或者TurboGears线路,这对公司没有什么,对个人是个选择。
>
> > 今天部门的内部知识分享活动中,刘鑫指出了过往对框架和库对比的问题:
> > - 混淆了运行期和开发期的不同对象, 进行了不必要的对比
> > - 库其实都是开发期的代码/dll ... 是不开发者直接面对的
> > - 框架其实重点是照顾运行期内存对象的,是更加接近用户的
> > 所以,框架多是包装了基些领域知识/经验,形成了内建规范/限制,来确保运行期的对象安定;也从而从整体上降低了应用的开发成本;'
>
> 库与框架都有运行期和开发期的问题。其实我认为Martin
> Flower的解释挺不错。框架与库的主要区别我认为是:框架会主动调用你写的东西,而库则是由你来调用的。正如写GUI程序一样,对于事件处理,是由框架来自-动调,而不是你控制的。
>
> --
> I like python!
> UliPad <<The Python Editor>>:http://code.google.com/p/ulipad/
> UliWeb <<simple web framework>>:http://uliwebproject.appspot.com
> My Blog:http://hi.baidu.com/limodou- 隐藏被引用文字 -
>
> - 显示引用的文字 -
--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110747] Re: 关于Pythonic哲学的一点思考

limodou
2009/11/27 sootoo <[hidden email]>:
> 我认为,好的框架应该是由"模块化的库组装成的。"
>
> 在快速开发阶段,可以使用现成的组合工具,在解决性能问题或特殊需求时,开发人员可以方便的替换库。
>
> 当然,这种框架设计思想也存在问题:模块耦合度低,会导致性能下降,代码重复等问题。
>

这种替换就和依赖式注入的概念很象。当然如何实现,实现到什么程序,哪些地方要实现,不同的框架实现的方式和标准就不同了。各种框架多多少少都有类似的功能。

--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110822] Re: 关于Pythonic哲学的一点思考

Bugzilla from xrfang@gmail.com
我在写些webpy小程序的时候,自己不由自主的就写了一些和jsp taglib中类似的一些小东西,比如:

$:h.select() -- 产生html <select>标记
$:h.options() -- 产生html<option>标记

等等。其实我相信,无论是Django还是Pylons等等,没有一个大家所说的“FullStack”框架不提供这样的便利性工具的。一个框架是否
Pythonic,我想,不光是道和术方面的考虑(仅仅这方面就有很多争论的),而且还要考虑的就是Python风格的问题。

关于python风格,我是python新手,虽然有我自己一点理解,可还是表达不出来;)以我个人这种(不一定正确)的对“道术”的认识为例,假设,
简单如webpy的就是“大道至简”就是Pythonic的,那么Webpy和Karrigell的对比呢?和PyHP的对比呢?我没怎么看
Karrigell和PyHP,只是看了一下他们的Hello World,怎么看怎么象PHPish,而不是Pythonic。

PHP也是很简单的,它只是一种语言,根本不是框架,如果因为“简单”、“Explicit”等原因将PHP说成Pythonic的,那再可笑不过了
(当然没有人这么说)。大家怎么看这个Python风格的问题?Pythonic != Simplicity,但Simplicity是
Pythonic的一部分,这我猜想大家会同意?

Python风格究竟是什么?


--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:110826] Re: 关于Pythonic哲学的一点思考

Zoom.Quiet
2009/11/28 xrfang <[hidden email]>:
...
> 关于python风格,我是python新手,虽然有我自己一点理解,可还是表达不出来;)以我个人这种(不一定正确)的对“道术”的认识为例,假设,
> 简单如webpy的就是“大道至简”就是Pythonic的,那么Webpy和Karrigell的对比呢?和PyHP的对比呢?我没怎么看
> Karrigell和PyHP,只是看了一下他们的Hello World,怎么看怎么象PHPish,而不是Pythonic。
>
嗯嗯嗯,Karrigell 可不仅仅有 象PHP 的撰写方式,有和 Web.py 一样的 .ks 方式...

> PHP也是很简单的,它只是一种语言,根本不是框架,如果因为“简单”、“Explicit”等原因将PHP说成Pythonic的,那再可笑不过了
> (当然没有人这么说)。大家怎么看这个Python风格的问题?Pythonic != Simplicity,但Simplicity是
> Pythonic的一部分,这我猜想大家会同意?
>
> Python风格究竟是什么?
>
这个好象在 Py教程中有提及:
- 象自然语言
- 没有多余语法声明(使用排版缩进来标识)
等等吧...

如果仅仅讨论写Python 的感觉和其它语言的不同:
参考:程序设计语言介绍
    http://floss.zoomquiet.org/data/20050206100400/index.html
和所有编译类语言相比,Python 不用过于担心数据类型的事儿,随手就可以相互转换;
和其它动态脚本語言相比, Python 更加轻松,因为我们有极完备的内置模块仓库,可以解决80% 的常见问题;
再具体点:
- C/C++/Perl... 小白和高手写出的代码完全不一样
- JAVA 小白和高手写出的代码几乎完全一样
- Python 小白和高手写出的代码大家相互都看的懂,看起来一样,认真看又处处不一样
所以,Pythonic 的代码风格应该是:
- 规范,整齐,每个函式不超过50行
- 模块划分合理,不会出现JAVA 那样7/8个点引用深对象树的情况
- 所有类/函式名,都非常干净,一致,直观
嗯嗯嗯,好象这些原则也可以应用到其它任何 OOP 语言的...
是也乎,是也乎! Pythonic 编程风格的确是通行的,不限于Python 的!


--
http://zoomquiet.org 人生苦短? Pythonic!
流程是对先前蠢行的内在反应! ~ Clay Shirky (Process is an embedded reaction to prior
stupidity)http://bit.l...

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:111037] Re: 关于Pythonic哲学的一点思考

Chen GUO-2
看了这么多讨论,突然想起我前不久的一则帖子,随手写写,玩笑而已,莫当真:
http://gc-daniel-0318.spaces.live.com/blog/cns!B6826F6CF83C99E!22521.entry
2009/11/25
青蛙的世界
小时侯学常识,知道青蛙只对在动的东西有视觉,那些不动的东西,它压根看不见,所以捉青蛙,一定要很慢,很慢,很慢,慢到,让它看不见,才能够抓得住
青蛙眼里的世界,大约就和我们看到的是一样的,满眼都是那些在变化的东西,却看不到不变
青蛙其实很适合混IT产业界,都是在不断的关注那些走马灯似的一会来一会去的泡沫,却不知道去思考一下那背后的几十年都不曾变化过的原理
比如,现在被炒的很热的云计算,青蛙就一定很感兴趣,就像几年前很多人对网格的热情那样3:13:49 | 添加评论 | 阅读评论 (4) |
固定链接 | 写入日志 | 感悟

On 11/28/09, Zoom.Quiet <[hidden email]> wrote:

> 2009/11/28 xrfang <[hidden email]>:
> ...
>> 关于python风格,我是python新手,虽然有我自己一点理解,可还是表达不出来;)以我个人这种(不一定正确)的对“道术”的认识为例,假设,
>> 简单如webpy的就是“大道至简”就是Pythonic的,那么Webpy和Karrigell的对比呢?和PyHP的对比呢?我没怎么看
>> Karrigell和PyHP,只是看了一下他们的Hello World,怎么看怎么象PHPish,而不是Pythonic。
>>
> 嗯嗯嗯,Karrigell 可不仅仅有 象PHP 的撰写方式,有和 Web.py 一样的 .ks 方式...
>
>> PHP也是很简单的,它只是一种语言,根本不是框架,如果因为“简单”、“Explicit”等原因将PHP说成Pythonic的,那再可笑不过了
>> (当然没有人这么说)。大家怎么看这个Python风格的问题?Pythonic != Simplicity,但Simplicity是
>> Pythonic的一部分,这我猜想大家会同意?
>>
>> Python风格究竟是什么?
>>
> 这个好象在 Py教程中有提及:
> - 象自然语言
> - 没有多余语法声明(使用排版缩进来标识)
> 等等吧...
>
> 如果仅仅讨论写Python 的感觉和其它语言的不同:
> 参考:程序设计语言介绍
>     http://floss.zoomquiet.org/data/20050206100400/index.html
> 和所有编译类语言相比,Python 不用过于担心数据类型的事儿,随手就可以相互转换;
> 和其它动态脚本語言相比, Python 更加轻松,因为我们有极完备的内置模块仓库,可以解决80% 的常见问题;
> 再具体点:
> - C/C++/Perl... 小白和高手写出的代码完全不一样
> - JAVA 小白和高手写出的代码几乎完全一样
> - Python 小白和高手写出的代码大家相互都看的懂,看起来一样,认真看又处处不一样
> 所以,Pythonic 的代码风格应该是:
> - 规范,整齐,每个函式不超过50行
> - 模块划分合理,不会出现JAVA 那样7/8个点引用深对象树的情况
> - 所有类/函式名,都非常干净,一致,直观
> 嗯嗯嗯,好象这些原则也可以应用到其它任何 OOP 语言的...
> 是也乎,是也乎! Pythonic 编程风格的确是通行的,不限于Python 的!
>
>
> --
> http://zoomquiet.org 人生苦短? Pythonic!
> 流程是对先前蠢行的内在反应! ~ Clay Shirky (Process is an embedded reaction to prior
> stupidity)http://bit.l...
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

[CPyUG:111039] Re: 关于Pythonic哲学的一点思考

Chen GUO-2
In reply to this post by Zoom.Quiet
看了这么多讨论,突然想起我前不久的一则帖子,随手写写,玩笑而已:
http://gc-daniel-0318.spaces.live.com/blog/cns!B6826F6CF83C99E!22521.entry

2009/11/25
青蛙的世界
小时侯学常识,知道青蛙只对在动的东西有视觉,那些不动的东西,它压根看不见,所以捉青蛙,一定要很慢,很慢,很慢,慢到,让它看不见,才能够抓得住
青蛙眼里的世界,大约就和我们看到的是一样的,满眼都是那些在变化的东西,却看不到不变
青蛙其实很适合混IT产业界,都是在不断的关注那些走马灯似的一会来一会去的泡沫,却不知道去思考一下那背后的几十年都不曾变化过的原理
比如,现在被炒的很热的云计算,青蛙就一定很感兴趣,就像几年前很多人对网格的热情那样3:13:49 | 添加评论 | 阅读评论 (4) |
固定链接 | 写入日志 | 感悟

On 11/28/09, Zoom.Quiet <[hidden email]> wrote:

> 2009/11/28 xrfang <[hidden email]>:
> ...
>> 关于python风格,我是python新手,虽然有我自己一点理解,可还是表达不出来;)以我个人这种(不一定正确)的对“道术”的认识为例,假设,
>> 简单如webpy的就是“大道至简”就是Pythonic的,那么Webpy和Karrigell的对比呢?和PyHP的对比呢?我没怎么看
>> Karrigell和PyHP,只是看了一下他们的Hello World,怎么看怎么象PHPish,而不是Pythonic。
>>
> 嗯嗯嗯,Karrigell 可不仅仅有 象PHP 的撰写方式,有和 Web.py 一样的 .ks 方式...
>
>> PHP也是很简单的,它只是一种语言,根本不是框架,如果因为“简单”、“Explicit”等原因将PHP说成Pythonic的,那再可笑不过了
>> (当然没有人这么说)。大家怎么看这个Python风格的问题?Pythonic != Simplicity,但Simplicity是
>> Pythonic的一部分,这我猜想大家会同意?
>>
>> Python风格究竟是什么?
>>
> 这个好象在 Py教程中有提及:
> - 象自然语言
> - 没有多余语法声明(使用排版缩进来标识)
> 等等吧...
>
> 如果仅仅讨论写Python 的感觉和其它语言的不同:
> 参考:程序设计语言介绍
>     http://floss.zoomquiet.org/data/20050206100400/index.html
> 和所有编译类语言相比,Python 不用过于担心数据类型的事儿,随手就可以相互转换;
> 和其它动态脚本語言相比, Python 更加轻松,因为我们有极完备的内置模块仓库,可以解决80% 的常见问题;
> 再具体点:
> - C/C++/Perl... 小白和高手写出的代码完全不一样
> - JAVA 小白和高手写出的代码几乎完全一样
> - Python 小白和高手写出的代码大家相互都看的懂,看起来一样,认真看又处处不一样
> 所以,Pythonic 的代码风格应该是:
> - 规范,整齐,每个函式不超过50行
> - 模块划分合理,不会出现JAVA 那样7/8个点引用深对象树的情况
> - 所有类/函式名,都非常干净,一致,直观
> 嗯嗯嗯,好象这些原则也可以应用到其它任何 OOP 语言的...
> 是也乎,是也乎! Pythonic 编程风格的确是通行的,不限于Python 的!
>
>
> --
> http://zoomquiet.org 人生苦短? Pythonic!
> 流程是对先前蠢行的内在反应! ~ Clay Shirky (Process is an embedded reaction to prior
> stupidity)http://bit.l...
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
来自: `python-cn`:CPyUG ~ 华蟒用户组 | 发言:[hidden email]
退订: http://tinyurl.com/45a9tb //针对163/qq邮箱:http://tinyurl.com/4dg6hc
详情: https://groups.google.com/group/python-cn
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
-~----------~----~----~----~------~----~------~--~---

12