知识积累整理::

邮件列表整理

《提问的智慧》

编程之道->编程之禅

TPCI--开发语言排行榜1

1. Freedom 综述

http://www.flosspols.org/images/logo_flosspols_kleur2.gif

Free-Libre and Open Source Software
自由/开放源代码软件 资料汇编

相关的思想性文章...

2. 知识森林

集中一些优秀的开源项目的文档,资料,代码,思想…………

2.1. LAMPs

若想进行跨平台的解决方案, 那就没有绝对的事情!

  • LAMPs-LAMP“明灯”照亮我们的Web事业

    • Linux 开源!最核心的动力!
    • Apache 最 Power 的 Web 服务器...

Apache.org 旗下汇集了无数强力的开源项目,严然与成为开源开发的管理中心

  • PHP - Hypertext Preprocessor

最流行的嵌入库试动态网页脚本

2.1.1. Linux

  • 拯救了自由的系统!

2.1.2. FreeBSD

2.1.3. Lisp

古老优美的脚本语言

2.2. DB

  • MySQL

最流行的快速轻型DB

最Mini的高级关系型DB

  • ZODB -- 高效对象型数据库

2.3. Text!

文可文,非常文。本可文,非常本。文本,数据之始,字符,万思之母...

文本作为最基础的数据格式从来没有在计算机世界中消失,而且以最快的发展速度在支持着我们最狂妄的需求!

2.3.0.0.1. 文本之歌

文本文件好,
工具遍地跑;
程序两三行,
全部改好了!

~ 文本文件好 - Blog on 27th Floor

2.3.0.0.2. 文档之歌

为机器写代码 ;
为用户做界面 ;
为老板做演示 ;
为同僚写文档 ;

~由吕毅发布的动态更新Buzz

2.3.1. 结构化文本[StructureText]

使用缩进和简单的符号来标识文档结构的文本

  • ST -- 基础结构化文本

  • reST -- 新结构化文本

    • Sphinx -- Python、Django 等开发工具的 reST 文档生成器

  • PyTextile -- 模糊化的标记文本

  • txt2tags -- 多模式结构文本 Python 应用!

  • AsciiDoc -- 简单方便的文本转换格式,支持HTML, Linux Man Page, Docbook

2.3.2. 标记文本[TagText]

标记文本!是XML的依存之道!

2.3.2.1. XML

2.3.2.2. 文章专用标签文本[DocBook]

2.3.3. TeX

  • LaTeX 使用技巧

  • Py2TeX将Python代码转换成TeX格式

2.3.4. 文本转换

2.4. 图象处理

含有章节索引的中文 文章模板

::-- hoxide [2005-07-29 19:08:23]

2.4.1. Python Imaging Library

2.4.2. ImageMagick

2.5. C / C++

2.6. Python

一种精心设计出来的脚本语言,使你可以快捷的实现任何愿望!

2.6.1. Pythonology 蠎学!

以动手实践为荣 , 以只看不练为耻;
以打印日志为荣 , 以单步跟踪为耻;
以空格缩进为荣 , 以制表缩进为耻;
以单元测试为荣 , 以人工测试为耻;

以模块复用为荣 , 以复制粘贴为耻;
以多态应用为荣 , 以分支判断为耻;
以Pythonic为荣 , 以冗余拖沓为耻;
以总结分享为荣 , 以跪求其解为耻;

2.6.1.1. 如何开始学习Python?!

2.6.1.2. Python 版本

追踪不同版本间的特性差异

2.6.1.3. Jython

差点儿死的咖啡蟒

2.6.1.4. 中蟒

总是被国人诟病的奇妙的Python 方言

2.6.1.5. Py Books

sizkim分享::

《Python编程金典》

PythonHowToProgram.jpg

PythonHowToProgram_book.zip 120Mb PDF格式
PythonHowToProgram_code.tar.gz

Pythonic 推广项目,组织,收集各种Python 学习,应用资料,进行推广宣传活动! Hoxide 发起

::-- ZoomQuiet [2005-03-20 04:58:51]

3. 缘起 Pythonic 推广

简述

  • 开源者, 不仅自己使用开放的软件, 同时也应该将这些美妙的东西介绍给别人, 共享是开源的精神基础. Python是我们的媒介, 是宣传开源和开源的切入点.

3.1. 推广计划

  • 2005 年 9-10 月, Python聚会? S(anghai/uzhou) Python User Group 发起? 组织活动?

3.2. 推广历史

  • 2004 年 3-6 月, Hoxide在数学学院机房, 6次讲解, 第一次将python介绍到了苏州大学.

  • 2004 年 11 月, Hoxide 《漫谈开源软件》, 将开源软件和开源精神作为一个整体一起介绍.

  • 2005 年 4 月, Hoxide 《漫谈python语言》, 一个时长两个小时的python介绍, 概览python的语言特性和应用实例. 其间还分发了刻有python软件的光盘.

  • 2005年 11月在北京师范大学,应邀进行一系列的宣讲活动 -- SpreadPyInBjTeachers

    • ..., Python 的科学应用?
  • 2007-03-17 在 bobo.com.cn 进行技术培训,推广Python -- AlbertLee

  • 2007-03-22 在 新浪内部进行技术培训,推广Python -- ZoomQuiet

3.2.1. 文宣资料

3.2.2. 年度回顾

3.2.3. 宣传画

chinese-python-poster.jpg

tg-contribute_docs.jpg

3.3. 资料收集

3.3.1. 中文资料

Python电子书本地收集 -- 啄木鸟空间发布

3.3.1.1. 精读类

3.3.2. 学习笔记

3.3.2.1. Py Tips

3.3.2.2. Python 学习笔记

Py 之灵活好学又是可以体现在大家各有入门妙方!倡议记录在案哪!

3.3.2.2.1. fall in Pythonic

初学者如何快速入门?

3.4. 讨论

4. 反馈

  • 是也乎是也乎!非常积极的活动,鼎力支持! -- ZoomQuiet

4.0.1. Py 4 distribute

{{{ejwe <jejwester@gmail.com> 回复: python-chinese@lists.python.cn 收件人: python-chinese@lists.python.cn 日期: 2005-11-24 下午2:29 主题: [python-chinese] 如何“编译”Python程序[转] }}} 如何编译python程序(或者如何由python生成可执行文件)是一个非常常见的问题,总是有人问,列出来,google搜索的时候就可以看到了。如果还有人说"找不到相关资料",唯一的解释就是这个人太懒了,根本没有去找。

如果转载,请注明出处。

  1. python(及其它高级的脚本语言)不存在把指令编译到本地代码的工具,但是总是可以发布可执行文件。

我觉得py2exe等等工具还是罗嗦,需要在配置文件中写上需要的数据文件作者完全无视这样一个事实:我需要发布可执行文件的时候,程序已经完工了,所有的数据文件就在主程序所在目录下,所以多数情况下,根本不用到别的地方搜索。

  1. py2exe http://py2exe.sf.net

只支持windows平台,应该是大家听到最多的一个名字了,用户不少,所以有问题的话在它的mail list里面很容易找到答案。文档中提到了"无法找到某某code"、使用opengl等模块的问题

  1. Installer http://www.mcmillan-inc.com/installer_dnld.html

可以产生windows、linux平台的可执行文件,现在作者主页连不上去了,但是搜索一下可以在其它地方下载 自带一个小程序写配置文件,如果程序较复杂,还是需要手工修改这个配置文件

  1. Python自带的freeze(不过windows版本不带这个,你可以自己下载python的源程序再找)。这个是我最不推荐的一种方法(为什么?自己看),不过如果你的python程序要发布到其它工具不支持的平台上,可以考虑这个方法
  2. 新出来的Pyco http://www.pythonapocrypha.com/projects/pyco/

还没用过

  1. Squeeze http://starship.python.net/crew/fredrik/ipa/squeeze.htm

还没用过,只支持python 1.4

  1. cx_Freeze http://starship.python.net/crew/atuining/cx_Freeze/

winodws、linux平台。简单的程序甚至都不需要写配置文件

  1. Stand alone Python for Windows http://arctrix.com/nas/python/standalone.html

如果你不介意源程序太过"暴露"的话,用这个吧 会不会觉得Updated: Sun, 09 Apr 2000 18:39:54 -0600 扎眼?如果你看一看它的VC源代码,就不会这么想了——其实这是普遍适用于win系统的方法,无论是98、2000或者xp。也许也可以用到linux上——我不懂linux,如果真的可以这么做,还请告诉我。

  1. py2app http://undefined.org/python/

支持linux平台的工具可能也支持mac os,或者直接使用这个py2app。具体就不知道了,只吃过苹果,还没玩过苹果呢

  1. 另类的方法,对python语言都还不是100%支持,众多的CPython模块也不可以使用,还有,我也没有试过:
    1. for .NET的python编译器(如Visual Python),不过我可不喜欢为了一个芝麻大的软件安装.NET framework
    2. 用jython,然后用jbuilder、jsmooth、NativeJ之类的包裹一下,或者用gcj编译成本地代码 http://blender.blogchina.com/523381.html

反馈

  • 还有使用 .egg 的 setuptools 那 —— ZoomQuiet

  • 我用wxPython给py2exe做了个界面,有兴趣可以试试.py2exe_gui —— 0.706

4.0.2. Py 4 Chinese

Python 中文 开发技巧

4.0.2.1. 中文Python资源

4.0.3. Py 4 IDE/GUI

Python 综合开发环境

Python GUI 开发技术

GUI 工具

Windows

Unix/X11

MacOS

Notes

Tkinter

(./)

(./)

(./)

最古老的Python GUI工具,基于tcl/tk,标准库中内置的GUI支持.参考书:John Grayson 的 Python and Tkinter programming.

PyGTK (+PyGnome)

(./)

(./)

(./)

Gnome的底层GUI库 GTK+ 的Python封装,并不推荐做跨平台使用.

wxPython

(./)

(./)

{X}

流行的跨平台GUI工具包 wxWindows的Python绑定.

PyQt

(./)

(./)

(./) (Mac Os 10)

KDE的底层GUI库,另一个流行的跨平台 GUI 工具包 Qt 的 Python 绑定.

FxPy

(./)

(./)

{X}

基于FOX的一个小GUI工具包,运行速度不错.

PyWin32

(./)

{X}

{X}

PyForDelphi

(./)

(./)

(./)

独立产品

* 将Flash应用于Python项目 -- Azureon

4.0.4. Py 4 Web

Python web 开发技巧

4.0.5. Py Web 应用平台(Application Frameworks)

WebProgramming - PythonInfo Wiki

Python WEB应用框架纵览

收集并描述各种基于Python 的WEB 开发平台,指引我们的敏捷开发

依大致国人关注度进行排序

5. 超级框架

5.1. Twisted

6. 主流框架

6.1. CherryPy

6.2. Django

6.3. TurboGears

6.4. Karrigell

6.5. web2py

  • 主页~ 号称企业级的web framework

  • Web2Py ~ 我们的体验!

6.6. web.py

6.7. Pylons

6.8. Quixote.堂吉诃德

6.9. Paste

6.10. Myghty

6.11. Zope系列

基础宣传
Zope3 时代
  • ZopeX3--全新开发的应用平台!

    • 但是!和ZOPE2的变化实在是太大了。难怪ZOPE3从2001年开始开发,一直到现在还有release呢,整个架构变了,连使用习惯都变了,对于想转到Zope3开发的人员来说是一个比较麻烦的问题。
  • Zope3Book -- 紧跟最新成果的翻译项目!honeyday 发起!

  • 三十分钟学会Zope3 -- 野火星兔

  • ZCA

Zope2 平台
CMF 框架

7. 国人框架

7.1. Uliweb

  • Uliweb -- 由limodou发起,多人参加的开源web框架。

7.2. 悟空智轮

  • WukooPy -- lihui 混合 Karrigell 和 Quixote 创造的 一个应用轮子

    • 哈哈哈!别直接龙了,叫 蟒龙是也乎?

7.3. pynixweb

  • 聚合所有的最佳实践
  • 力求简单有效

8. CMS框架

PyCMS系列收集

8.1. itools

8.2. payago

8.3. pylucid

8.4. skeletonz

8.5. teeny_tiny_cms

9. 边缘框架

9.1. Dabo

  • DaBo -- 又一个默默发展的快速开发平台!

9.2. Storm

9.3. Snakelets

9.4. ikaaro

  • IkaaRo -- 从工具包入手的CMS 构建包

9.5. atocha

  • atocha -- 一个围绕表单的web framework

    • 感觉还不错,可以考虑嵌在其它的web应用中用来生成表单 -- Limodou

9.6. robaccia

9.7. colubrid

9.8. aquarium

9.9. RhubarbTart

10. Pythonic Web 应用平台对比

更多的Py实现 CMS--内容管理平台
各种CMS 的对比见
http://cmsmatrix.org/uploads/HA/cO/HAcOzvnZorPtv5wLpUxtDw/cms_matrix.gif cmsmatrix.org

排序原则

平台

有大把時間做企業級應用

plone,zope

適合 python 專家用

pylons, webpy, twisted.web, zope

追求一體框架

django, zope/plone, karingel

適合快速上手

karingel, cherrypy. turbogears

快速 CMS

django

支援度

django, turbogears, pylons, zope/plone

框架自由度

pylons, turbogears

一般用途

django, turbogears, pylons

文檔優勢

django, turbogears, pylons

有 Rails 背景

pylons, turbogears

有 AJAX/javascript helper/widgets

turbogears/pylons

WSGI 支持度

pylons, turbogears(django努力中)

JSON(AJAX server side)

turbogears

並用 flash/flex

turbogears

10.1. 再次综合对比

10.1.1. limodou 曰

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

从级别上来说:

  • 轻量级:web.py karrigell cherrypy
  • 中量级:django, tg, pylons
  • 重量级:zope/plone
  • 从个人的体会:轻量级适用范围太小,象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程序员可能很难再去投入到一个看上去复杂的体系中了.我可能就是这样的.

10.1.2. 沈崴 曰

沈崴 <wileishn@gmail.com>                  hide details    12:36 am (40 minutes ago) 
        reply-to                python-cn@googlegroups.com       
        to      
        python-chinese@lists.python.cn,
python-cn@googlegroups.com       
        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

个请求每秒的速度。至于 CherryPy3TurboGears 是否能用, 在下也还没有尝试过。

  • 如果在同级应用中 TurboGears系能和 Django 分庭抗礼, 我个人觉得只有一个可能, 那就是 TurboGears (或者直接说 CherryPy)要更简单一些。我个人最先接触到 CherryPy, 这样 TurboGears 系在实际中就用得更多一些, 但是这并不说明我喜欢 TG 要超过 Django。

  • 5. web.py 是对 Django、TurboGears 这些框架的反动, 既然不能像 Plone 这样大而全, 何苦搞得那么复杂?

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

10.1.3. doudou 曰

{{{doudou doudou <array.doudou@gmail.com> hide details 1:04 pm (3 minutes ago)

}}} 我学的不多,暂且比较一下吧。

  • mod_python,直接用这个编程的人不多,如果你比较喜欢了解一些细节和直接控制这些细节的话,则是首选,与其他几种RAD框架相比mod_python简直就是汇编,可用的几个寄存器确保你学起来并不困难,但是写程序往往要写很多。
  • cherrypy,我以前曾经很喜欢这个东西,也是我学过的第二个框架,简洁就是美,至今也没有发现什么很不爽的地方,只是他比mod_python高级不了多少,还是有很多东西需要自己重新写。那时同时也学了Cheetah,感觉不错。
  • Pylons,一个恶梦,学起来并不简单,到了用的时候更是一塌糊涂。我还受到要求用它写过一个应用,后来因为Pylons的下属某个组件版本升级,乱写日志,就直接pass了。从此以后不用Pylons。
  • TurboGears,因为有cherrypy的基础,一直很想学,只是出于实在没空,其中的表单提交验证是很方便的东西。我涉足TG很浅,知道的也很少,不多做评论,不过由于是与Pylons一样的由多个组件构成,难保各个组件版本难以协调。即便是相同的TG版本也难以确保各个组件的版本与之前安装的都相同。

  • web.py,用作嵌入式服务器和嵌入的WEB管理界面还可以,很方便。可以随着应用一起发布,无需安装,简直就是太完美了。不过说实在的,web.py的代码写的很巧妙,是我至今读过的很多WEB框架代码中最让我激动的,其中很多理念非常先进。
  • django,最近正在学,开发速度较快,基本可以满足我的要求。只是,很多都是重新开发的,所以我以前积累的很多Python各类组件的知识都用不上了。
  • 总体来说,推荐django,国内文档比较多,缺陷就是没有一本官方的书(写完的),而TG就有一本很不错的书。
    • 如果你时间不是很急的话,推荐你先把web.py的代码看看,然后看看cherrypy的代码,再用Twisted自己实现一个小的框架,之后你就会发现那些框架原来差别并不大,学起来也可以用一些模式来学。
    • 当然谈到自己实现一个框架,说实在的并不难,我以前那个Pylons的应用因为组件升级导致日志混乱之后,一气之下就用Twisted实现了一个小的框架。也许这也是为什么Python的框架这么多的原因,因为写起来并不难。我的这个框架在我的AMD 64双核台式机上面,每秒可以处理1500+个请求。同样的条件下web.py是720req/s,Pylons是610req/s。至于mod_python,尽管很熟,但是安装比较麻烦没有测试。

10.2. 综合对比

Re: 关于 Python 的 web 开发框架,应该选择哪个?

  • limodou
    web framework大多数从功能上都大同小异。从功能上分:zope/plone算大型的,而django,
    turbogears算是轻量级的。从学习曲线上分,zope/plone要长一些,而django,
    turbogears相对要短一些。对于django,
    turbogears来说,开发的理念有所不同,但功能是类似的。django所有东西都是自已开发的,象模板系统,url映射机制,ORM等。而turbogears则是许多相对成熟项目的集合,这一点与pylons也很象,如模板系统主要是kid,通过模板适配可以使用其它的模板(强调一下,django是松耦合的,许多组件也可以替换),web
    server组件使用cherrypy,ORM使用SQLObject(还可以使用SQLAlchemy)等等。关于这两种集成的方式,不同的人有不同的看法。有人认为turbogears是好的,因为没有重新造轮子。但有些人象我认为集中式更易管理和控制。所以关键看你认同哪一种设计理念。
    对于ajax也有许多不同的声音。ajax本身可以与后台无关,它主要是在前端通过javascript,
    DOM来操纵前端数据,与后台交互。从这一点上,任何web
    framework都可以算是支持ajax。如果说不支持,那是从后台能否自动生成相应的html,
    javascript代码这一层来说的。turbogears嵌入了mochekit的js库的支持,可以通过python程序生成相应的js代码。django则是有人做过这样的工作,但要么不是成熟的东西,要么还没有成型。为什么会这样也与django的设计理念有关系。象turbogears,它的支持是针对不同的js库生成不同的包装,这样如果js库非常多,自然会有许多的包装,目前已经是这样的。而django在讨论是则不希望是这样,希望有一个中间层或无关层,但的确这一点很难。因此后来可能限定在了dojo,不过还没有相关的代码可以看到。只不过admin功能使用了dojo的一些东西。
    还有pylons也很有特色。但对于我上人来说,我认为它太复杂了,不容易理解,所以也没有人研究过。目前国内对于django,
    turbogears, pylons都有人研究,从人数上看是比例依次递减。对于zope/plone则有专门的czug.org,有许多人在学习和研究。
    总之,不同的框架从基本功能上是大同小异,在功能是各有特色的,设计理念上也是各有差异。选择一个框架不仅看它的功能是否满足,可能还有许多的因素,如人气,成熟度,是否有现实的应用,性能,设计理念等等。应用从方面进行考查,而且用着顺心可能更重要。象karrigell作为初学入门,或更轻量级的选择也是不错。
    --
    I like python!
    • ZoomQuiet

      从学习成本来看就三种层次:
      1:Zope 系列的高成本复杂性平台,维护需要深入学习成本,带来整体的稳定;
      2:Django 等的中等复杂度平台,通过各种组合,使用一定的框架概念,中度学习后,可以获得丰富的功能,和一定数量级别上的稳定;
      3:web.py 类的极低学习成本,可以直接进入开发和同步运营,一切功能都可以自行快速开发出来,但是系统整体稳定性依赖开发人员的成熟度
      平台的选择主要看你的应用原则,和运维手段,是想依赖平台的设计,还是开发人员的人品?
      总之学习成本和对系统整体细节的掌控程度是呈反比的。
    • 没有人否认 Zope-Plone 是最好的 base Python Web app. 平台,
      但是, Zope2 也好 Zope 3 也好,都是有极高的学习曲线的,
      就好象一个E国人,明知中文的唐诗是最优美的语言艺术,
      但是他想恰当的引用诗句和真正可以自如的创造出古体诗的学习成本,
      就好比我们要合理合法的深入使用Zope 平台和基于Zope进行二次开发的学习成本!
      所以,就个人想立即享受,体验Python 的web app.应用开发,使用 Karrigell/web.py 吧!
      想快速将Python 引入商业站点的快速开发,使用 Django/TurobGears 等等框架吧!
      如果想真正服务永继的进行 web 服务的话,还是 Zope 3 吧!

10.2.1. 关注Ajax 时

From: gasolin@gmail.com <gasolin@gmail.com>  Mailed-By: googlegroups.com
Reply-To: python-cn@googlegroups.com
To: "python.cn" <python-cn@googlegroups.com>
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 是非常适合的选择.

10.2.2. Django 体验

10.2.2.1. Romit~我对django的看法

Romit <m_list@126.com>
reply-to        python-chinese@lists.python.cn,
to      python邮件列表 <python-chinese@lists.python.cn>,
date    Dec 13, 2007 11:05 PM
subject [python-chinese] 我对django的看法

2006年末因为接手单位的网站,面对一个烂摊子,怎么能在短时间内让这个网站
焕然一新成为我面临的首要问题。
重造车轮式的方法显然是不可取的,更何况我也不是一个高手,所以就在互联网上
狂搜现成的框架。搜了一堆,首先是
zope,其次是plone,然后是什么tiger之类还有webpy之类,当然还有django。权衡
再三选择了django
第一、学习周期短
我花了2天多一点时间基本上就把django搞清楚了,而zope这个框架太庞大了,看
了一个多月没有搞出什么头绪来,plone
更是如此,tiger之类的呢完全是堆砌的产品(不喜欢,不过不知道这个东东怎么样)
第二、开发速度快
记得写第一个新闻发布系统的时候,大概就是一下午左右的样子,包括前端的AJAX
后台当然是自带的了,我觉得对很对象
我这种公司不给投入的人来说,无疑是一种福音,不管怎么样领导要的是一个结果。
第三、架构比较简单
规则表达式的url简单易用,基本功能一应俱全,特别是数据接口这块,特别适合
不熟悉数据库的人。经典的MVC式框架,对于
不是从事web开发的人员来说也是非常的清晰明了。

说完优点,说说缺点吧。
第一、管理界面比较呆滞,不容易扩展,听说下一个版本已经有所改善。
第二、django的应用管理不适合有变动需求的项目,为什么这么说呢,主要问题出
在django的模型和应用管理这块上,这两块
的功能实在太弱了,如果你不用管理平台这个问题压根就不存在。如果你使用它的
管理平台,对模型的更改首先是管理平台立即宕机,
其次是框架无法对数据库进行相应的更改,除非你对这个项目进行重新的部署,但
是一旦重新部署,你就会发现你的管理平台上所作的
任何权限的配置都无法生效,原因在于数据库内的权限系统已经被污染,除非你在
部署项目的时候,进入django的权限管理数据库系统内
首先清楚先前的项目。也有的网友提出了相应的解决方案:
1、导出数据
2、清除权限配置
3、部署应用
4、导入数据
也就是说django在应用管理上比较弱。
第三、原生数据库支持有点少,扩展的不在讨论范围之内。

目前还没有发现有性能方面的问题。

10.2.3. TurboGears vs Django

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

10.2.3.1. gasolin 曰

{{{发件人: gasolin@gmail.com <gasolin@gmail.com> 回复: python-cn@googlegroups.com 收件人: "python.cn" <python-cn@googlegroups.com> 日期: 2005-9-19 下午9:32 主题: TurboGears vs Django }}}这几天从limodou兄的blog中看到 TurboGears 这个框架,看完演示教程后相当为之惊艳.

Django 跟 TurboGears 的出现提供了一个相当 pythonic 的解决方案 (python + HTML :D).

不需要使用资料库查询语言(SQL)或额外的资料库设计修改工具是一大特色.

TurboGears (Python) 是在 cherrypy +SQLObject等的基础之上整合相当成功的框架.

其计划的核心概念是不重复发明轮子, 而是把 python中的各轮子组成有用的框架.计划主要的工作是提供简化的安装, 设定, 操作,与文件.

  • 我们的 WuKooPy 也是这意思,不过关注的深度比较浅 -- ZoomQuiet

之前 Ruby on rails 超热的时候似乎 python 社群有个 SUBWAY计划想达成类似的事情,但一听就知道是想复制 ROR 的计划,并未提出相当的成果.

两者较不同的是 Django提供预设的资料库增删修改介面, 而 TGP似乎还没发展这块.

比起 Django 来说, TurboGears 更吸引我的是整合 AJAX 支援,

Django 跟 TurboGears 相比无论安装, 使用上都复杂许多,而 Django 从头开发也意味着目前 python web开发社群要使用这框架也得多花费心力去学习.

TGP 是由 python script 组成的 controller 呼叫 SQLObject来读出资料库中的资料,再以字典形式传值到样板中当作动态语言的变数.

达成资料库(model)->controller->template (View) 的 MVC 架构

传出的格式如

{data=content, pagename=page.pagename}

这样一次收集所有用到的参数,接收用

<div py:replace="data"/> Page text goes here. </div>

这样在标签中加"py:replace"的格式插入参数,

Ruby on rails 或 Django 每加一页新的资料, 要处理的 MVC关连似乎不及TurboGears 承袭 cherrypy架构(不知有无说错?)的简单明了

TurboGears 教程中是由单一的 controller (标准的 python class) 呼叫 SQLObject来读出资料库中的资料, 再以字典形式传值到样板中当作动态语言的变数.

 达成资料库(model)--controller--template (View)  的 MVC 架构.

  • 由 controller 传出的格式如 {data=content,pagename=page.pagename}

一次收集网页样板将用到的 data 跟pagename 参数.

网页样板 template 接收用

<div py:replace="data">内容显示在这里</div>

实际显示时会将"内容显示在这里"这段替换成资料集"data"中的内容.

要在网页样板中调用这几个参数有两个方式.

  • 第一种是可以在标签中加py:replace="data", 来插入 data字典参数;

  • 或是使用类似一般动态语言给参数的方式 ${data} 插入data 字典参数.

    • 注意第二种的格式还是跟 python调用字典的感觉很像.

间中用到的 HTML, ini 都算是基本的内容,用起来没什么要另外学东西的负担.

Django (或 Ruby on rails)每加一页新的资料,都要分别处理对应的 controller.关连似乎不及 TurboGears 承袭 cherrypy 架构可使用单一controller 的简单明了(不知有无说错?)

  • 因此我认为相比之下 TurboGears 成功的机率更大些.

10.2.3.2. limodou 曰

{{{回复: python-chinese@lists.python.cn 收件人: python-chinese列表 <python-chinese@lists.python.cn> 日期: 2005-11-14 上午10:24 主题: [python-chinese] Django vs. TurboGears }}} [wiki:PyCNmail/2005-November/019026.html Django vs. TurboGears]

看到列表中讨论 Django 和 TurboGears 的多了起来,我想就这两个web framework提出自已的一些看法,因为哪个都算不上精通,只是对某些方面多一些罢了,至今天除了按照django的教程做了一下,某它的就没做过。TurboGears方面也只是学过CherryPy而已,不过我从我个人的关注角度出来,希望对它们进行比较一下,大家可以补充,让比较更客观。另外因为我对DjanGo关注稍多一些,可能对于turbogears有些不正确的观点,请大家见谅。

  • DjanGoTurboGears 的优点

    1. 自动的admin界面,有用户和组的管理,这些代码不用你写了
    2. generic view,减少你写view的代码,模板当然还是要的
    3. 模块及模板均支持i18n。
    4. url采用正则表达示很有创意,这样可以规则你的url。另外通过正则表达式可以构造与方法调用无直接关系的链接形式,搜索引擎支持好。
    5. DjanGo的模板还可以自已扩展,很有趣,可以增加新的tag和filter,而且写起来挺简单。

    6. 有middleware,可以自已编写
    7. 应用安装方便
    8. 开发团队集中,目标一致
    9. 已经有网站的应用
  • TurboGearsDjanGo的优点

    1. ORM模块采用sqlobject,比DjanGo中的要成熟

    2. 支持ajax
    3. 充分利用了setuptools工具
    4. 宣传力度大,人数多,相对DjanGo活跃

  • 共同的优点:

    1. 文档做得都不错
    2. 都象ROR一样提供相应的命令行工具

  • 我的感觉是: -- ZoomQuiet

    • TG 是聪明的大杂烩,但是每种主料发展的不均衡一定会影响到TG的,当然集成 Ajax 是非常吸引人的
    • Dj 是一个美妙的新轮子 MTV 非常炫,但是远离了Pythonic, 回到Unix 神秘的命令行时代了,而且DB 操作调试,更加没谱了……
  • 这两天在看 TG 感觉到 TG并没有因为 它的杂而影响到他,相反的很多组建开始依赖 TG 来开发了,而且 TG 开始引入 Plugin的概念了,原来集成在 tg里面的 kid 模板组建 从 r459 开始分离出了TG 这样 TG现在就有了很多的 Template engine 了 TurboCheetah ,TurboStan TurboKid,TurboZpt ,这些个 Template engine 都会为 TG 带来更多的新鲜血液,吸引更多的开发者. 还有 ORM ,估计 Kevin Dangoor 也会渐渐的将 SQLObject作为 plugin来集成在 TG里面了,这样更多 好东西都会慢慢加入 TG了,但是估计CherryPy是换不掉了,现在看tg的maillist Kevin Dangoor 和 Cherrypy的团队合作很密切.呵呵,然后就是很让人期待的事情了 Kevin 打算在 pycon2006之前发布 1.0版本,现在每天就是看 TurboGears Repository Commits 都有些什么更新.

还有 TG的 Toolbox组件也非常的让人期待 modelDesigner的出现使得建模更加的快速和简单了,真正突显出了 TG 的快速开发. by bib

10.2.3.3. InterMa 补充

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

  • 基本框架思想
  • URL 调度系统
  • 模板系统
  • ORM 支持
  • 表单处理
  • 扩展类型应用
  • 高级应用
  • 框架已知缺点
  • 框架未来发展

}}}

  • 大概意思是褒Dj贬Tg,不过个人还是比较喜欢Tg,希望她能度过难关。
  • 是也乎,俺也是看好TG ,奈何未成气候 -- ZoomQuiet

寻找类似ROR的web框架的讨论:/SimilarToRor--TomZ

11. 自由评注

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

11.0.1. P2P

  • KenoSis -- 构建p2p网络的基础框架

11.0.2. P4EE

Python 企业环境应用探讨 Python for Enterprise Environment

11.0.2.1. mod_python

与Apache 紧密结合的支持组件!终于可以完好运行了

11.0.2.2. Zope

11.0.2.3. Dabo

  • DaBo -- 又一个默默发展的快速开发平台!

11.0.3. Pythonic 模板

11.0.3.1. GenShi

http://genshi.edgewall.org

  • 特点:解释型模板,纯粹面向 xml,流式的处理机制,能够嵌入 python 语句和表达式,提供强大的功能。
  • 从 Kid 发展而来,比 Kid 更灵活,性能也更好,实现部分 XPath,XInclude 规范。
  • TurboGears 默认的模板引擎将从 Kid 转为 GenShi

11.0.3.2. MaKo

http://www.makotemplates.org/

  • 特点:编译型模板,卓越的性能,将 Python 语言优雅得植入模板中,功能强大。
  • 由 Myghty 发展而来,是对 Myghty 的重新设计和重新实现,类似 GenShi 和 Kid 的关系。

  • PyLons 默认的模板引擎将从 Myghty 转为 MaKo

11.0.3.3. JinJa

http://jinja.pocoo.org/

  • 特点:编译型模板,类似 django 模板的简洁语法,适合网页设计师使用。继承和发扬了 django 模板在安全性方面(SandBox)的考量,限制模板的能力,有专门机制防止模板修改数据和访问危险代码!

  • 与 django 模板主要区别在于:编译 vs 解释,macro,支持 python 表达式。另外还有一些细节上的区别,见:Differences To Django Templates

  • 根据 FAQ,性能大概三倍低于 mako,两倍高于 django 模板。

11.0.3.4. ClearSilver

ClearSilver是一个高性能的模版系统,让我们看看他的使用网站,就知道他的表现有多好。

  • Bloglines
  • Google Groups
  • Yahoo Groups

http://www.clearsilver.net/img/misc/Clearsilver-Architecture.gif

11.0.3.5. 印度豹

Cheetah - http://www.unrealtower.org/mycheetah

http://www.cheetahtemplate.org/cheetah-face-black-medium.jpg CheetahTemplateOrg -- 一个历史悠久的JAVA 模板系统的衍生,可以生成一切文本文件

11.0.3.6. Myghty Google 的利器

myghty_small.png MyghtyOrg -- 一个高速模板系统,几乎可以独立作为web 应用平台来使了

11.0.3.7. Kid

Kid 是一种简单的基于 XML 的模板语言,它使用嵌入的 Python 语句来对某些元素进行处理,它的语法借鉴了许多现存的模板语言,诸如 XSLT、TAL、PHP等等。

Kid 的设计目标是为了简化 Python 对 XML 文档的处理。同其它 XML 工具相比:

  • SAX、DOM、ElementTree 等 API 可以保证输出是组织良好的,但要求文档必须用 Python 创建。

  • Cheetah、PTL 等模板语言很容易使用,但不能保证输出结果是组织良好的。
  • XSLT 提供了许多函数来产生良好的 XML 文档,但要求所有输入必须是 XML 文档格式,用起来也不怎么简便。

Kid 则试图结合所有上述技术的优点。

Kid 可以用来产生任何形式的 XML 文档,包括 XHTML、RSS、Atom、FOAF、RDF、XBEL、XSLT、RelaxNG、Schematron、SOAP 等等。

11.0.3.8. 其它

PyWork - http://pywork.sourceforge.net

Subway - http://subway.python-hosting.com/

Spyce - http://spyce.sf.net

ZQ 收集对比

11.0.3.9. 讨论

自动Spamer 攻击,无奈关闭自由评注

11.0.4. Py 4 Mobile

Python 在移动设备中的开发

  • PyMobileDev -- 如何在移动设备中开发Python 应用

11.0.5. Python 实用开发包

11.0.6. Python 扩展与嵌入

11.0.6.1. Py in M$

11.1. JavaScript

最基本的动态Web 技术,但是研究下去...

11.1.1. Javascript学习

11.1.2. 实用框架

  • JsEasy JsEasy一个开源的Ajax开发辅助库.它提供了一系列的Javascript函数和Css特效,使您的前台开发如虎添翼_

  • JsValidationFramework -- 表单验证框架 JVF 的啄木鸟再次开发项目

11.1.3. Ajax

令JS 重新注目于世界的小花招

  • GoogleAjax -- Google 组织的Ajax 实现 -- 清风发起

  • PyBurlap -- Burlap协议的Python实现

11.1.4. 幻宇

11.1.5. 月影

  • Zerg:模仿PYTHON语法的JS框架

11.1.6. web在线游戏DEMO(斗地主)

11.1.7. bobby作品

  • [JS白之绊测试版]-可完成剧情|地图|战斗|存储
  • 演示地址 : http://bzb.gbq.cn

11.1.8. listView示例

11.1.9. web20 js框架

11.1.10. Javascript Diff

11.2. 文学编程

11.3. 软件工程

11.3.1. 设计模式

11.3.2. IOP

  • PyIOP ~~ Infrequently Oriented Programming -- 面向少见模式编程

11.3.3. 算法研讨

语言之外的天地

11.4. e-Learning 开放学习

电子学习? 互联时代的全新学习方式,在研究领域中是使用开源精神进行构筑的!

11.4.1. 思考·学习工具

11.5. Google.com

虽然是.com 但是!Google 从来不排斥开源!

11.5.1. GTalk - Jabbar 的盛宴!

  • GoogleTalkBot -- Google Talk Group 群聊守护机器人

    • 根据开放API 快捷完成的功能!!

11.6. Mozilla.org

绝对的开源项目中心,不仅仅是浏览器是也乎!

11.6.1. Greasemonkey

当红的客户端插件开发环境!

-- Zoom.Quiet [2004-08-04 23:17:26]

  1. 这个排行榜每月更新一次,其排名顺序按照世界范围内的技术工程师、讲师、第三方厂商的调查依据,并查询了目前流行的搜索引擎:Google,MSN, Yahoo,结合前两者的数据计算后得出的。根据TIOBE的观点,此排行榜是被程序员们用来检查自己的程序技能是否过时,或者作为建立新的软件系统时进行参考之依据,并非意味着哪种语言是最好的 (1)

FLOSS (last edited 2009-12-25 07:13:51 by localhost)

  • Page.execute = 4.780s
  • Page.execute|1 = 3.222s
  • Page.execute|2 = 1.970s
  • Page.execute|3 = 0.925s
  • Page.execute|4 = 0.278s
  • getACL = 0.225s
  • init = 0.001s
  • load_multi_cfg = 0.000s
  • run = 4.952s
  • send_page = 4.941s
  • send_page_content = 4.786s
  • send_page_content|1 = 4.370s
  • send_page_content|2 = 2.899s
  • send_page_content|3 = 2.098s
  • send_page_content|4 = 1.099s
  • send_page_content|5 = 0.135s
  • send_page|1 = 4.531s
  • send_page|2 = 3.082s
  • send_page|3 = 2.325s
  • send_page|4 = 1.375s
  • send_page|5 = 0.267s
  • total = 4.953s