TableOfContents

1. Pythonic Web 应用平台对比

1.1. 再次综合对比

1.1.1. limodou 曰

limodou <[email protected]>              hide details    4:52 pm (8 hours ago) 
        reply-to                [email protected]   
        to              [email protected]   
        date            Jul 8, 2007 4:52 PM      
        subject         Re: [python-chinese] 现在python的web框架这么多，有没有人能分析分析各自的优点缺点？

从级别上来说：

从个人的体会：轻量级适用范围太小,象web.py, karrigell还算全面,而cherrypy就应该只算一个web server级的了,许多东西都没有,大量的要自已去做.从这三者中如果要选择,我会选择karrigell.karrigell更接近php,功能比较多,模板丰富.

不过既然是轻量级,自然会过渡到更高量级的框架上,这是随着你对web开发的要求越来越高,比如ORM, 模板,更好的组织方式,自动化的功能,可参考的项目等等因素.

从中量级已经有过不少人对tg和django进行比较,在ibm开发者网站上还有过,网上也不少,不过可能大多是比较ROR与django.从设计哲学上来看,tg与pylons很接近,它们都是若干个项目的集成,而且目前越来越趋同,比如都使用mako模板,sqlalchemy这个ORM.而且有一个sprint是在pylons上跑tg,不过没有仔细研究过.大量地使用了wsgi.构建基础是在setuptools之上,甚至还使用了setuptools提供的插件机制可以从网上自动安装东西.

而django则可以认为是一站式的框架,不象tg/pylons需要安装大量的第三方的模块,安装django很简单,以前有阵子django的安装框架也是使用setuptools,但是因为使用了setuptools,如果你的python不是2.5以上版本,因此setuptools不是内置的,所以需要单独安装,后来django团队认为这个并不能带来什么好处,因此它内置不信赖于setuptools的某机强大的机制,再加上对于没有安装setuptools的人并不方便,所以就改为原始的setup方式了.所以从这里也可以看出django的设计是集成化的方式,与tg/pylons差别之巨大.因此有人想过何时tg与pylons会合并也正是因为它们设计思路的接近,而django与其它两者之间基本上是不可能的.关于django的功能不想过多的介绍了,应该有不少,最大的特点要算是：admin功能自动生成,正则式方式的url设计,简洁而拘谨的template,自成体系的ORM,出色的i18n的支持,目前又已经将unicode分支合并到主干上来了.

从三者出现的时间来说：django>tg>pylons.

我为什么选择django,主要是django的设计哲学与我个人的习惯接近,我认为django安装使用方式,不用自动从网上下载若干个模块,对安装非常方便.而且因为django出来的早,所以在没有发布前就从python邮件列表中得到消息就已经开始关注了,所以对它的态度可能有些先入为主.再加上django最具影响力的就是Guido van Rossum这位python的创始人在多个场个宣传他喜欢django,就是在最近的Google developer day上,在北京见到这位＂明星＂他还在说：＂I like django＂.因为我想他的一个观点就是：＂Simple is the best.＂. 当然象大朗所说学习成本高要看怎么说了.如果你的要求高,django有许多高要求的东西,学起来自然很高.如果你的要求低,功能自然差了许多,而且可以使用admin,所以学习成本不高.而且每种框架都有自身的难度,深入下去自然要求比较高.这种高要求也许不全是学习成本,比如有些功能可能框架就没有, 这种难度就不再是学习的难度而是需要由你设计或寻找一个可用实例的难度了.

web框架我要说：因为简单的会不够用,所以迟早会选择一个功能强大全面的框架.框架需要有活力,有发展.要看自身的要求与关注点,从多个框架中选择一个合适自已的.至少从功能来说django/tg/pylons是差不多的,而如果tg/pylons如果合并的话,就有两个功能相当,适合两种不同的使用习惯的人使用了.

zope/plone可能需要专业从事web开发的人长期的投入,它就象一片大海,让人很难摸清楚.zope我只学过zope2,而且还是只会使用dtml, zclass, python script来开发,象product, tal都没有使用过.而zope3更不要说了.而plone是基于zope之上的一个cms的产品,功能更强大,内容更多.学习zope/plone更多的是在使用产品,大量的时间可能是花在学习zope和plone的组件的学习上,而不是python本身.而django/tg/pylons则许多还是依赖于python的语法功能,如decorator等,还是可以明显得看出python的东西来,学习的感受不太一样.再如zope3中采用了xml来描述配置,引入了interface,这些在其它的python开发中应用并不广泛,不能说它不好,只是说可能与一般的python程序员所追求的＂Simple is the best＂可能不太一致.习惯了简单东西的python程序员可能很难再去投入到一个看上去复杂的体系中了.我可能就是这样的.

1.1.2. 沈崴 曰

沈崴 <[email protected]>                  hide details    12:36 am (40 minutes ago) 
        reply-to                [email protected]       
        to      
        [email protected],
[email protected]       
        date            Jul 9, 2007 12:36 AM     
        subject         [CPyUG:28791] Re: [python-chinese] 现在python的web框架这么多，有没有人能分析分析各自的优点缺点？   
        mailed-by               googlegroups.com

赵老师, 您好! 我曾走马观花地尝试过上述某些框架, 略有些感想, 希望能对您有所帮助 :)

0. Limodou 关于这些工具级别的阐述说得很好!

1. Ruby on Rails, 当项目进行到一半的时候, 所有人都意识到这其实是一个错误。因此, 我们放弃了 ROR。对 Python 程序员而言, 除非 ROR 带来的商业利益超过成本上的支出, 否则很难适应 ROR 的效率。打个比方, 在 Plone 中尽管你可以使用 ArchGenXML 通过 UML 图来建立 Plone 应用, 但是真正开始使用后, 我们会发现手写 Archetypes 代码其实要比画 UML 图要来得方便和快捷。

2. Zope/Plone 是我现在完成所有应用的首选。Plone 已经自带用户、权限等系统, 你完全没必要自己作任何事情。Archetypes 拥有难以置信的建模能力, 搜索引擎和增删改页面全自动生成。Plone 自带的工作流引擎允许你靠鼠标完成工作流设计。使用得当, Plone 能带来几十倍的开发效率提升。Plone 也有非常严重的问题。首先, 几乎所有人都认为 Plone 很慢, 事实上, Plone Skin 带来了太多 IO, 明白这一点, 我们能把 Plone 加速到和 CherryPy2 不相上下的程度。其次, 很多人对 Plone 定制苦不堪言, 但是如果不过于依赖 Plone Skin, 那么这也不是一个问题。最后, Plone 的栈很深, 不是所有人都会有足够耐心花几年时间来熟练地使用她, 这才是真正的问题 (在下认为这是完全值得的)。

3. 当应用不足以用到 Plone (比如我突然要为字符终端程序编写一个系统后台守护进程), 特别地, 当 Plone 过于完善的系统反而完全束缚了我们, 既然 Django 看上去是目前最好的框架, 这时候我选择 Django。这或许从一个侧面反映了一个在国内鲜为人知的情况, 那就是无论是国内还是国外, 使用 Plone 的应用要远超过 Django, 但是 Plone 程序员不会告诉你哪些站点是用 Plone 开发的, 因为这太偷懒了。常常, 这时任务会简单到直接使用 SimpleHTTPServer.py 就可以解决, 因此即使是一个临时方案, Django 还是很少被我用到。

4. TurboGears 系的程序员或许会感慨没有像 Django 那么好用的 URL 映射系统, 这是个意想不到的大问题, 因为黑客或许会选择像 TG 那样通过重用构建起来的东西, 但是他们更喜欢正则。作为 TurboGears 系的一员, 小弟斗胆猜测大家的潜台词可能都是: 我们爱 CherryPy 这样的好东西, 这带来了另一个意想不到的大问题: Apache Proxy 已经是一个 Tree Mount 和正则发布系统, 无论对 CherryPy 还是 Django 这都绝对不是一个好消息。接下来, CherryPy 也没有传说中那么快, CherryPy2 已经是有定论了, 而我测试的 CherryPy3 通常也没有能达到 500 个请求每秒的速度。至于 CherryPy3 的 TurboGears 是否能用, 在下也还没有尝试过。如果在同级应用中 TurboGears 系能和 Django 分庭抗礼, 我个人觉得只有一个可能, 那就是 TurboGears (或者直接说 CherryPy) 要更简单一些。我个人最先接触到 CherryPy, 这样 TurboGears 系在实际中就用得更多一些, 但是这并不说明我喜欢 TG 要超过 Django。

5. web.py 是对 Django、TurboGears 这些框架的反动, 既然不能像 Plone 这样大而全, 何苦搞得那么复杂? 在下认为, web.py 的作者同样对 SimpleHTTPServer.py 这类的标准库同样非常不满。不过有点尴尬, 我对各种层次的应用都已经有合适的方案了, 而目前所有流行框架不能完成的事情 web.py 同样也搞不定。在下意识到或许所有人对于 web.py 因为各种原因都会有些痒。但是这不妨碍 web.py 的优秀和学术价值。

1.2. 综合对比

[wiki:2006-June/025580.html Re: 关于 Python 的 web 开发框架，应该选择哪个？]

1.2.1. 关注Ajax 时

From: [email protected] <[email protected]>  Mailed-By: googlegroups.com
Reply-To: [email protected]
To: "python.cn" <[email protected]>
Date: Jun 9, 2006 2:15 PM
Subject: [python-cn:10720] Re: 关于 Python 的 web 开发框架，应该选择哪个？

补充一点心得:
如果你的网页应用服务主要关注在 AJAX 应用,
大部分动作都用 javascript 在客户端完成,
只有 data 部分需要后端提供. 那么 TurboGears
是非常适用的选择.
1. 可以先用一般 serverside
开发方式写函式和建立网页应用服务原型 (prototype),
来测试你的网页应用服务该有的功能.
   @expose(format = ".template.pages") #资料以样版格式显示
   def method(self):
   ....
   return dict{data=data}
因为 TurboGears 中从传入 serverside 的表单资料处理一致,
所以在 serverside 写的 code 完全可以继续使用,
不必为了支持 AJAX 重写,
很好的达到不重复自己(DRY)的效果.
2.import javascript library , 将资料改以 JSON 格式传到网页
from turbogears import mochikit
...
@expose(format = ".template.pages") #资料以样版格式显示
@expose(format = "JSON") #资料以JSON格式显示
def method(self):
....
return dict{data=data, scripty = mochikit} #在网页上
TurboGears 预先包好 mochikit, scriptaculous, plotkit 等 javascript
库,
使用时可以用程式呼叫, 预设可用 JSON 格式传输,
预设 mochikit 库提供相应资料处理支援.
3. 在 client 端用 javascript 处理 DOM 物件.
因为在开发的第一步时已经能将所需的资料,
传输内容等都处理好了,
能确信资料传输的正确性. 所以开发 javascript 时,
可以专注在网页内资料处理的部分.
在这时遇到 bug
的话也可以很放心地将可能的问题点缩小到单纯网页内资料处理的范围,
因而 AJAX 开发时最麻烦的交叉 debug 也变得更容易.
因此如果你的网页应用服务主要关注在 AJAX 应用, 那么
TurboGears 是非常适合的选择.

1.2.2. TurboGears vs Django

对比集中在高压力环境稳定性和sqlobject的发展结合上

1.2.2.1. gasolin 曰

Include(TGvsDjGasolin)

1.2.2.2. limodou 曰

Include(TGvsDjLimodou)

Include(PyWebFrameDiscuss)

1.2.2.3. InterMa 补充

{{{节译: 主要比对方面:

}}}

2. 自由评注

频率受到Spamer 攻击!070528关闭自由注释功能