以在python社区总有关于python框架孰优孰劣的话题。下面就给大家介绍一下python的几大框架：
django
django 应该是最出名的py框架，google app engine甚至erlang都有框架受它影响。
django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起orm，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。
django提供的方便，也意味着django内置的orm跟框架内的其他模块耦合程度高。
应用程序必须使用django内置的orm，否则就不能享受到框架内提供的种种基于其orm的便利；理论上可以切换掉其orm模块，但这就相当于要把装修完毕的房子拆除重新装修，倒不如一开始就去毛胚房做
全新的装修。
django的卖点是超高的开发效率，其性能扩展有限；采用django的项目，在流量达到一定规模后，都需要对其进行重构，才能满足性能的要求。
而django的缺点主要源自django坚持自己造所有的轮子，整个系统相对封闭，django最为人诟病的地方有：
· 系统紧耦合，如果你觉得django内置的某项功能不是很好，想用喜欢的第三方库来代替是很难的，比如下面将要说的orm、template。要在django里用sqlalchemy或mako几乎是不可能，即使打了一
些补丁用上了也会让你觉得非常非常别扭。
· django自带的orm远不如sqlalchemy强大，除了在django这一亩三分地，sqlalchemy是python世界里事实上的orm标准，其它框架都支持sqlalchemy了，唯独django仍然坚持自己的那一套。django的
开发人员对sqlalchemy的支持也是有 过讨论和尝试的，不过最终还是放弃了，估计是代价太高且跟django其它的模块很难合到一块。
· template功能比较弱，不能插入python代码，要写复杂一点的逻辑需要另外用python实现tag或filter。django的模板系统设计十分有意思，也应该其框架内影响最大、争议最大的部分。
django模板的设计哲学是彻底的将代码、样式分离；asp.net提倡将代码/模板分离，但技术上还是可以混合；而django则是从根本上杜绝在模板中进行编码、处理数据的可能。
比方说，asp.net模板中可以写：
<%
int i;
for(i==0;i<10;i++){
....
}
%>
django是彻底不支持嵌入类似上面的代码，仅能使用其模板内置的函数；这实际上，是为其模板构造了一种“新语言”；由于此“新语言”十分简单，所以也能够将其模板移植到不同平台。
大多数情况下，django的模板功能是足够的，但对于特殊（有时“特殊”也不是十分特殊）的情况，还是需要在模板中嵌入代码，那么就需要根据其模板系统的规则做模板扩展。有时候，模板中直接写
一行代码能够解决的问题，用模板扩展实现后，会变成十几行代码。
是否容忍在模板中编程，正是django模板争议最大之处。
pylons & turbogears & repoze.bfg
除了django另一个大头就是pylons了，因为turbogears2.x是基于pylons来做的，而repoze.bfg也已经并入pylons project里这个大的项目里，后面不再单独讨论turbogears和repoze.bfg了。
pylons和django的设计理念完全不同，pylons本身只有两千行左右的python代码，不过它还附带有一些几乎就是pylons御用 的第三方模块。pylons只提供一个架子和可选方案，你可以根据自己的喜好自
由的选择template、orm、form、auth等组件，系统高度可 定制。我们常说python是一个胶水语言(glue language)，那么我们完全可以说pylons就是一个用胶水语言设计的胶水框架。
选择pylons多是选择了它的自由，选择了自由的同时也预示着你选择了噩梦：
· 学习噩梦，pylons依赖于许多第三方库，它们并不是pylons造，你学pylons的同时还得学这些库怎么使用，关键有些时候你都不知道你 要学什么。pylons的学习曲线相对比django要高的多，而之
前pylons的官方文档也一直是人批评的对象，好在后来出了the definitive guide to pylons这本书，这一局面有所改观。因为这个原因，pylons一度被誉为只适合高手使用的python框架。
· 调试噩梦，因为牵涉到的模块多，一旦有错误发生就比较难定位问题处在哪里。可能是你写的程序的错、也可能是pylons出错了、再或是sqlalchemy出错了、搞不好是formencode有bug，反正很凌
乱了。这个只有用的很熟了才能解决这个问题。
· 升级噩梦，安装pylons大大小小共要安装近20个python模块，各有各自的版本号，要升级pylons的版本，哪个模块出了不兼容的问题都有可能，升级基本上很难很难。至今reddit的pylons还停留在
古董的0.9.6上，sqlalchemy也还是0.5.3的版本，应该跟这条有关系。
pylons和repoze.bfg的融合可能会催生下一个能挑战django地位的框架。
tornado & web.py
tornado( http://www.tornadoweb.org )是facebook开源出来的框架，其哲学跟django近乎两个极端。tornado即是一个web server(对此本文不作详述)，同时又是一个类web.py的micro-framework。
tornado走的是少而精的方向，它也有提供模板功能；虽然不鼓励，但作者是可以允许在模板进行少量编码（直接嵌入单行py代码）的。
如果跟asp.net相比，tornado有点类似仅实现了asynchttphandler；除此之外，全部需要自己去实现。
好吧，其实它有模板，有国际化支持，甚至还有内置的oauth/openid模块，方便做第三方登录，它其实也直接实现了http服务器。
但它没有orm（仅有一个mysql的超简单封装），甚至没有session支持，更不要说django那样自动化的后台。
假设是一个大型网站，在高性能的要求下，框架的各个部分往往都需要定制，可以复用的模块非常少；一个以django开发的网站，各部分经过不断的定制，django框架剩下的，很有可能也就是tornado一
开始所能提供的这部分。
殊途同归。
http服务器
tornado为了高效实现comet/后端异步调用http接口，是直接内嵌了http服务器。
前端无需加apache / lighttpd / nginx等也可以供浏览器访问；但它并没有完整实现http 1.1的协议，所以官方文档是推荐用户在生产环境下在前端使用nginx，后端反向代理到多个tornado实例。
tornado本身是单线程的异步网络程序，它默认启动时，会根据cpu数量运行多个实例；充分利用cpu多核的优势。
单线程异步
网站基本都会有数据库操作，而tornado是单线程的，这意味着如果数据库查询返回过慢，整个服务器响应会被堵塞。
数据库查询，实质上也是远程的网络调用；理想情况下，是将这些操作也封装成为异步的；但tornado对此并没有提供任何支持。
一个系统，要满足高流量；是必须解决数据库查询速度问题的！
数据库若存在查询性能问题，整个系统无论如何优化，数据库都会是瓶颈，拖慢整个系统！
异步并**不能**从本质上提到系统的性能；它仅仅是避免多余的网络响应等待，以及切换线程的cpu耗费。
如果数据库查询响应太慢，需要解决的是数据库的性能问题；而不是调用数据库的前端web应用。
对于实时返回的数据查询，理想情况下需要确保所有数据都在内存中，数据库硬盘io应该为0；这样的查询才能足够快；而如果数据库查询足够快，那么前端web应用也就无将数据查询封装为异步的必要
。
就算是使用协程，异步程序对于同步程序始终还是会提高复杂性；需要衡量的是处理这些额外复杂性是否值得。
如果后端有查询实在是太慢，无法绕过，tornaod的建议是将这些查询在后端封装独立封装成为http接口，然后使用tornado内置的异步http客户端进行调用。
以上就是深入了解常用的python web的几大框架 的详细内容。