python开发网页框架,Python的web框架
简介：作者飞龙写的《浅谈Python Web框架》。他介绍了一些Python Web框架，并分析了他对框架的选择。在他看来，用Django快速开发一些网络应用是个不错的选择。以下是文章内容：
说到网络框架，Ruby的world Rails是一个统一的世界，而Python是一个百花齐放的世界。微框架和框架数不胜数。查看不完整列表：
另一种更大的脚本语言PHP也有很多框架，但没有Python那么夸张。也就是说，因为Python Web框架(Python Web Development Frameworks，以下简称Python框架)太多了，所以Python社区里一直存在着哪个Python框架更好的话题。
Python有那么多框架，没多少人能单独玩。坦白说，我只用过其中的三个开发项目，其他的我也有一点点接触，这里只能说一下。欢迎开朗的朋友补充。
Python框架开满了花，但那种房子最大。那是大真。要说Django是Python框架里最好的，有人赞同，有人坚决反对。不过我想大家对说Django文档最全，市场占有率最高，招聘岗位最多都没有意见。Django受到称赞主要是因为：
完美的文档，这是Django成功的一大原因。我认为Django多亏了几乎完美的官方文件(包括Django的书)。
提供完整的解决方案。Django和Rails一样，提供了完整的解决方案(全框架架构)。基本需要的东西)比如Django，一个开发cache、session、feed、orm、geo、Aution等网站的工具，基本就是为你设计的。所以开发效率不言而喻，即使有问题也很容易发现，不是在你的代码里，而是在Django的源代码里。
强大的URL路由配置允许Django设计非常优雅的URL。你可以和Django中丑陋的GET参数说再见了。
自主管理的背景，管理界面是Django中备受关注的贡献。它不需要一行代码就可以拥有一个完整的后台管理界面。
Django的缺点主要源于Django坚持自己做所有的轮子，整个体系比较封闭。姜戈最恶毒的地方在于：
如果系统之间耦合紧密，你觉得Django的一些内置功能不好，很难用你喜欢的第三方库(比如ORM，Template等)来替代。下面介绍)。在Django上用SQLAlchemy和樱井真子几乎不可能，打补丁也很不协调。
Django拥有的ORM要比SQLACHEMY强大的多。除了Django的三个移动部分，SQLACHEMY实际上是Python世界的ORM标准。其他框架中支持SQLAlchemy Django的开发者也讨论过，也尝试过支持SQLACHEMY，但最后都放弃了。成本太高，而且似乎很难和Django的其他模块集成。
模板功能较弱，无法插入Python代码。要编写稍微复杂的逻辑，需要用Python实现标记和过滤。到目前为止，关于模板有很多争论，但是最近有两篇关于Python模板的有趣文章：
网址结构性强，但必须手写。这完全违背了Rails对配置概念的约定，而且最初了解Hitachidxs和Django的人提供的URL也大相径庭。
忧的Auth模块和Django的auth与其他模块紧密结合，功能也非常强大。只是，有点过头了。用户的数据库模式已确定。那样的话，就有问题了。例如，许多站点需要唯一的电子邮件地址，但是该字段的值在模式中不是唯一的。担心是必要的。
Python文件被用作配置文件，而不是ini、xml、yaml等更常见的格式。这本身不是问题，而是因为理论上settings的值是动态变化的。虽然人们不这么做，但这不是最佳实践的体现。
总的来说，因为Django的包比较大，用它快速开发一些网络应用还是不错的。如果你遵循Django的设计理念，你会发现Django很好用，越用越方便。相反，如果你不能吸收或接受Django的设计理念，用Django一定很痛苦。你最好早点放弃。所以，对一些人来说姜戈就像长生不老药，但对另一些人来说，姜戈是毒药，而且剧毒无比。
除了Django，另一个大头是挂架。TurboGears2.x是基于Pylons的，但是repoze.bfg也纳入了Pylons项目这个大项目中，所以不单独讨论TurboGears和repoze.bfg。
Pylons和Django的设计理念完全不同。Pylons本身只有大约2000行Python代码，但几乎所有代码都带有第三方的Pylons模块。Pylons只提供一个货架和选项方案，所以要根据自己的喜好。
模板、ORM、表单、auth等组件由选择，系统高度可定制。我们常说Python是胶水语言，所以可以说Pylons是用胶水语言设计的胶水框架。
选择塔台主要是选择它的自由度。选择自由也说明你选择了噩梦：
学习噩梦，挂架依赖很多第三方库。它们不是由塔架制造的。你必须在学习塔的同时学习如何使用这些库。关键是有时候连自己想学什么都不知道。塔的学习曲线远高于Django，塔的官方文档也一直是被诟病的对象。幸运的是，《铁塔权威指南》这本书出版了，这种情况已经改变了。由于这个原因，Pylons曾经被认为是只适合hdsdxs的Python框架。
调试噩梦，因为涉及的模块很多，一旦出现错误，很难定位问题。可能是你写的程序错了，或者是Pylons错了，或者是SQLAlchemy错了，也可能是formencode有bug，反正乱七八糟的。这个问题只有熟悉了才能解决。
升级噩梦，安装挂架需要大大小小近20个Python模块，每个模块都有自己的版本号。要升级Pylons的版本，有可能是任何一个模块出现了不兼容的问题，升级基本上是非常困难的。到现在reddit的挂架还卡在古风的0.9.6版本，SQLAlchemy还在0.5.3版本，应该和这个有关系。
Pylons和repoze.bfg的整合可能会催生下一个可以挑战Django地位的框架。
Tornado是一个Web服务器(本文不再详细描述)，同时也是一个类似于web.py的微框架，作为一个框架，Tornado的思想主要来源于Web.py，你也可以在Web.py的主页上看到Tornado的老板Bret Taylor的这段话(这里提到的FriendFeed使用的框架可以看作是Tornado的一个东西):
“[web.py启发了]我们在FriendFeed使用的web框架[以及App Engine附带的webapp框架……”
因为这个关系，以后就不单独讨论龙卷风了。
Web.py的设计理念力求简洁有力。总共没有多少行代码，也不像挂架那样依赖大量第三方模块。而是只为一个框架提供一些必要的东西，比如URL路由、模板、数据库访问，剩下的就交给用户自己了。
精简框架的优势在于，您可以专注于业务逻辑，而不必过多关注框架本身或被其干扰。同时缺点也很明显，很多事情都要自己打理。
我个人更喜欢这种简化的框架，因为通过阅读源代码，你很容易理解整个框架的工作机制。如果框架部分不是很满意，我完全可以用Monkey patch按照自己的要求来。
Bottle和Flask作为jmdlt生成的Python框架的代表，有趣之处在于它们都采用decorator来配置URL路由，比如：
从瓶子导入路径，运行
@route(/:name )
定义索引(name=World ):
return bHello %s！/b“% name
运行(host=localhost ，port=8080)
瓶子和烧瓶，像web.py，都很简洁。瓶子，甚至所有的代码都在里面。两千行的py文件。另外Flask和挂架一样，可以和Jinja2，SQLAlchemy之类的很好的结合。
但目前瓶瓶结合的成功案例很少。
之所以特别提到《堂吉诃德》，是因为国内最大的用Python开发的网站Douban.com就是用《堂吉诃德》开发的。我只是简单的翻了翻源代码，没有做任何研究，也不做评论。我有经验补充一下。我只是在想，如果现在把Douban.com交出来发展，会有更多的选择。
其他(web2py，uliweb，Karrigell，Werkzeug …)
对最终框架选择的误解
在框架的选择上，很多人很容易陷入以下两个误区而不自知：
1.哪个框架最好？——世界上没有最好的框架，只有最适合你和你的团队的框架。编程语言选择也是如此。如果您的团队最熟悉Python，请使用Python。如果你最熟悉Ruby，就用Ruby。编程语言和框架只是工具。多做、快做、好做、少做是好事。
2.过于注重性能3354其实大部分人并不需要过于注重框架的性能，因为你开发的网站根本就是一个小站。能访问一万个IP地址的网站不多，能访问十万个IP地址的网站更是少之又少。在达到一定访问量之前谈性能没有太大意义，因为你的CPU和内存总是处于闲置状态。而且语言和框架一般不是性能瓶颈，性能问题往往出现在数据库访问和文件读写中。PHP的Zend框架是出了名的慢，但是Zend框架有大站，比如digg.com；经常被说性能有问题的Ruby和Rails还能开发twitter吗？再者，现在的硬件和带宽成本其实很低。尤其是有了云计算平台，人力成本是最贵的。没有几万个IP，你根本不用太在意性能问题。如果流量上去了，花点钱买些服务器空间，简单快速的解决性能问题。
注：此前有网友质疑我“Quora是用挂架开发的”的说法不客观。我先说清楚，这里说的某个网站A是用B开发的，只是说A主要或者部分是B开发的，所以我们不要再纠结于A还用c了。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。