Django用久了，难免会感觉到*度不够。不可否认，这种*度的牺牲能够带来一些好处。比如，一体化的框架（full-stack framework)能够提供全面的solution，你不需要再为cache,session,feed,orm,auth,template等问题困扰，完全按照Django的设计哲学来使用就可以了。使用Django能够快速开发应用，而且技术的统一对于团队开发来说无疑是一件好事，团队成员无需在技术选型上进行过多的争论——Django已经帮我们定好了，just DO it。
但是在提供全面的solution的同时，Django将自己打造成了一个封闭的框架。由于所有的组件都靠自己实现，可能在每一个方面都做得不够好（尽管够用）。同时为了方便使用，Django的各个组件之间耦合比较紧密，你很难将某个组件替换成你自己喜欢的库。比如Django最为人诟病的ORM和Template，如果你想替换成SQLAlchemy和Mako，几乎是不可能的事情。即使勉强使用，也会让你非常别扭。
话说天下大事，分久必合。在python web framework 的战国时代，Django几乎做到了一家独大。但如果其他的框架合纵联合，未必不能与Django一争高下。
现在这种融合的趋势已经显现，而Django如果依然固步自封，即使再强大，也会在历史的尘埃中销声匿迹。如果你不相信，我们可以追索一下事实真相，不难看出这种融合恰恰是从更加强大的Zope的分裂开始的。
在《戏说WSGI》一文中，曾经列举了几个python web框架。其中Zope是一个另类，因为Zope非常厚重，适合组织大规模的开发，构建复杂的应用。为了能够面对更高的复杂度，Zope提供了一个组件框架ZCA (Zope Component Architure)，引入了接口的概念，使得复杂系统可以基于接口开发。ZCA提供了适配器组件，用于装配整个应用的各个组成部分，还进一步提供了可重用的工具组件，事件组件等。可以说，ZCA是Zope中最有价值的产品。
尽管ZCA能够将Zope提供的认证、对象发布、事务管理、授权等功能组装起来，但是这些功能在Zope之外还是很难使用。于是有了Repoze项目。Repoze的目标是将Zope的功能组件拆解出来，使得其他的python web应用能够使用。说到这里，不禁又要感慨一下WSGI的重要意义：WSGI定义了Web服务器和Web应用以及Web中间件之间的交互协议，只要支持WSGI，各种web服务器、web应用和中间件就能相互对接。而Repoze正是将Zope组件按照WSGI进行封装，从而遵循WSGI的python web 框架可以很容易使用这些组件。
最初，Repoze推出了自己的一个非常轻量级的web框架：repoze.bfg。在repoze.bfg中利用了ZCA的特性。于是python web framework世界中又多了一方*。但恰恰是这个不起眼的小*推动了历史的进程。repoze.bfg和Pylons类似, 几乎都是完全的策略*（policy-free），你可以随意的指定数据持久层，模板系统等外围部分，而其核心就是约定了URL如何映射到 view 代码以及如何调用view，在这个过程中完全遵循WSGI规范。后来repoze.cfg的开发者决定将其合并到Pylons。于是拉开了Python web框架合并的序幕。这个合并的框架叫做Pyramid。无独有偶，原本基于Pylons的TurboGears也宣布开发基于Pyramid的分支。
至此，混乱的江湖看到了统一的希望，相信越来越多的python web框架会融合，或至少能够互通。或许，随着更加开放的框架的出现，Django会慢慢淡出大家的视野，让我们拭目以待。