- Django
Django 是一个高级的 Python Web 框架，支持快速开发，简洁、实用的设计。如果你正在建一个和电子商务网站相似的应用，那你应该选择用 Django 框架。它能使你快速完成工作，也不必担心太多的技术选择。它能提供从模版引擎到 ORM 所需的一切东西。用 Django 构建你的app 的时候，你必须要遵循 Django 的方式，这点像极了 Ruby on Rails 的 Rails 框架。有些人会觉得这样有点不爽，但在我看来这是极好的，毕竟我坚信：“约定优于机制”。相对于所有其他的库，Django 框架有最强的社区，这意味着可以轻松获得帮助。
- Flask
Flask 是基于 Werkzeug，Jinja 2 的 Python 轻量级框架（microframework）。注意——“microframework” 里的 “micro” 可能会产生误解。轻量级不意味着 Flask 是一个不成熟、不靠谱的库。它表示 Flask 的核心就是非常非常简单的。不像 Django 框架，它不会给你带来技术选择上的问题，你可以自由选择你喜欢的任何模版引擎或 ORM。即使它默认配备了 Jinja 模板引擎，你也随时可以自由选择。 在我看来，用 Flask 来编写 API 服务（RESTful rervices）是再好不过的。
- Twisted
Twisted 是用 Python 实现的基于事件驱动的网络引擎框架。它是一个高性能的引擎，其快速的主要原因是一个被称为 deferred 的 object，Twisted 是建立在 deferred object 之上。对于不了解 deferred object 的人来说，deferred object 是通过异步架构实现的机制。Twisted 是很快速的，但是不适合编写常规的 WebApps。如果你想做一些底层网络的东西，Twisted 是你的好帮手。
- Tornado
Tornado 是一个 Python Web 框架和异步网络库，最初是由 FriendFeed 开发的。Tornado 采用非阻塞网络 I / O 模型，可以处理数以千计的网络连接，这意味着对于 long polling 、WebSockets 和其他需要长时间实时连接的 apps 来说，Tornado 是一个理想的 Web 框架。Tornado 介于 Django 和 Flask 之间。如果你想要用 Django 或 Flask 写一些东西，但你想要一个更好的性能，你应该选择用 Tornado 框架。配合上合理的架构，它能很好的处理 C10K 问题。
- Cyclone
-
http://cyclone.io/
Cyclone 是用 Python 编写的一款异步非阻塞的轻量级 Web Server 框架。它实现了 Tornado 的 API，底层实现是基于 Twisted Protocol 的。现在，如果你想要 Twisted 的性能和易于编写常规的 webapps，那么请选择 Cyclone。相对于 Tornado 框架，我更喜欢 Cyclone。它有一个非常类似于 Tornado 的 API，实际上，它是 Tornado 的一个 fork 分支。但是问题就是它拥有的社区相对较小。Alexandre Fiori 是主要代码贡献者。
- Pyramid
Pyramid 是一个通用的，开源的 Python web 应用开发框架。其主要目标就是让 Python 开发人员更轻松的开发 web 应用程序。我没有用过 Pyramid 框架，但是我看过它的文档。据我了解，Pyramind 和 Flask 很相似，我认为可以用 Flask 框架的地方也可以用 Pyramid 框架，反之亦然。
原文地址：dhilipsiva
标签: python常用框架对比
Django
优点：
- 大和全（重量级框架）
- 自带orm，template，view
- 需要的功能也可以去找第三方的app
- 注重高效开发
- 全自动化的管理后台（只需要使用起ORM，做简单的定义，就能自动生成数据库结构，全功能的管理后台）
- session功能
缺点：
- template不怎么好用（来自自身的缺点）
- 数据库用nosql不方便（来自自身的缺点）
- 如果功能不多，容易臃肿
Tornado
优点：
- 少而精（轻量级框架）
- 注重性能优越，速度快
- 解决高并发（请求处理是基于回调的非阻塞调用）
- 异步非阻塞
- websockets 长连接
- 内嵌了HTTP服务器
- 单线程的异步网络程序，默认启动时根据CPU数量运行多个实例；利用CPU多核的优势
- 自定义模块
缺点：
- 模板和数据库部分有很多第三方的模块可供选择，这样不利于封装为一个功能模块
总结：
要性能， Tornado 首选；要开发速度，Django 和 Flask 都行，区别是 Flask 把许多功能交给第三方库去完成了，因此 Flask 更为灵活。
综上所述：
Django适合初学者或者小团队的快速开发，适合做管理类、博客类网站、或者功能十分复杂需求十分多的网站
Tornado适合高度定制，适合访问量大，异步情况多的网站
Django 概述
Django 应该是最出名的python框架，Google App Engine甚至Erlang都有框架受它影响。 Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。 Django提供的方便，也意味着Django内置的ORM跟框架内的其他模块耦合程度高。 应用程序必须使用Django内置的ORM，否则就不能享受到框架内提供的种种基于其ORM的便利；理论上可以切换掉其ORM模块，但这就相当于要把装修完毕的房子拆除重新装修，倒不如一开始就去毛胚房做全新的装修。 Django的卖点是超高的开发效率，其性能扩展有限；采用Django的项目，在流量达到一定规模后，都需要对其进行重构，才能满足性能的要求。 Ruby的Rails也有类似的问题；以Twitter为例，推特到了今日的规模，不要说Rails，甚至是连Ruby都需要抛弃重来。 就我的感觉Django适用的是中小型的网站，或者是作为大型网站快速实现产品雏形的工具。
Tornado 概述
Tornado是Facebook开源出来的框架，其哲学跟Django近乎两个极端。Tornado是异步框架Tornado基本上只算有MVC中C这一层 Tornado走的是少而精的方向，它也有提供模板功能；虽然不鼓励，但作者是可以允许在模板进行少量编码的。 如果跟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对此并“没有”提供任何支持。 这是Tornado的“设计”，而不是缺陷。 一个系统，要满足高流量；是必须解决数据库查询速度问题的！ 数据库若存在查询性能问题，整个系统无论如何优化，数据库都会是瓶颈，拖慢整个系统！ 异步并**不能**从本质上提到系统的性能；它仅仅是避免多余的网络响应等待，以及切换线程的CPU耗费。 如果数据库查询响应太慢，需要解决的是数据库的性能问题；而不是调用数据库的前端Web应用。 对于实时返回的数据查询，理想情况下需要确保所有数据都在内存中，数据库硬盘IO应该为0；这样的查询才能足够快；而如果数据库查询足够快，那么前端web应用也就无将数据查询封装为异步的必要。 就算是使用协程，异步程序对于同步程序始终还是会提高复杂性；需要衡量的是处理这些额外复杂性是否值得。 如果后端有查询实在是太慢，无法绕过，Tornaod的建议是将这些查询在后端封装独立封装成为HTTP接口，然后使用Tornado内置的异步HTTP客户端进行调用。
Odoo是一个商业套件，并不是严格意义上的 web框架。
最初的Odoo叫TinyERP,后来改名叫OpenERP，再后来改名叫Odoo,
这几年接触到了flask, tornado,django,odoo之后。在独立开发方面odoo貌似具备无可比拟的优势。我应该不是odoo学习最深入最了解的人吧。但odoo大概也是最轻松的的。odoo的结构设计本身就是为了模块化，企业化。不得不说相比于django和flask这种迭代开发的模式。odoo更加偏向于一次成型，二次迭代。当一个功能产生到后面迭代。不会出现太多了次数。因为odoo会随着经手人的增加。迭代的次数增加越来越难用。在最初恰恰是最易用的时候。
实现了这么多年的迭代和非迭代的需求。大部分功能其实都围绕一个主逻辑的细枝末节。并不需要持久开发。只有跟商业模型相关的主逻辑会不断的迭代。所以其他很多逻辑在这个程序员实现功能到上线代码。很长一段时间不会发生变动。只要能用。只有在产品完成一个大版本之后慢慢不管精修枝叶。而这一切其实符合odoo的概念和运行逻辑。
odoo在中国使用存在一个落地难的问题。odoo内部存在大量的erp模块。可以随意微调。这恰恰也是很多中国公司和团队使用odoo的原因吧。不管是我还是我朋友都被落地这个问题所坑到。国情不同。逻辑不同。二次开发做调整还是重新开发。而重新开发到底要不要用odoo这些问题都是被稀里糊涂的回答。
只能说按照自己需要去解决。后续主要编写大概也是一些odoo 11 的一些基本结构和戏法。还有属性介绍吧。在odoo模块构成中最初也是最让人舒服的模块构成。所以除了使用odooweb模块外不使用odoo任何app。二次开发真的没什么。有足够的水平之后不断阅读理解。然后在关键位置做更改罢了。
但重新用odoo开发模块真的会比二次开发慢很多吗？？
如果考虑好所有商业逻辑。odoo的开发速度不会让任何人失望。在我足够熟练的时候甚至比django更快。就更别提flask和tornado了。每个人因为各种各样的理由吧。仅仅只是证明这个可能性。在去掉一大块精华的同时也去掉绝大多数的糟粕。保留了odoo最低绝对精华的部分吧。只有在足够了解熟悉的情况下。在考虑启用部分odoo应用为宜。这其中需要花费大量的时间而我自认不足以应对。
