pylons 看了好久了，喜欢的他精简封装，就想它自己的名字一样，“ 架线塔 ” 松散话。说是框架，其实也不是框架。
只是把一些模块结合起来，随着对pylons的了解的越来越深入，越着迷。其中好些信息看文档是不深入的，一些疑惑
还是要看pylons的源码的（别怕，pylons的源码核心没多少），说回来，python的web开发不都是围绕wsgi 走的吗？
本质就不复杂，有些框架复杂，是外围太庞大了，把本质掩盖在里面。
pylons 的核心就是 “ 垂直的 Middleware + 横向的 Controller ”
Middleware 就像是千层饼 外部的 “ 层饼 ”
Controller 就是里面的 “ 馅 ”
有 “ 肉馅千层饼” ， “豆沙千层饼” ......
Middleware 在系统级别上 垂直复用。 Controller 在应用逻辑级别上 平行处理
一些关键点：
1、程序的入口:
$app\config\middleware.py 中的
make_app(global_conf, full_stack=True, static_files=True, **app_conf):
global_conf 等一系列参数，都是通过解析配置文件得到的。
config = load_environment(global_conf, app_conf) 中 把 route 的mapper 也包含在里面了。
这个config 可以说是运行环境了。
接下来关键点
2、 app诞生
app = PylonsApp(config=config)
app 被注入运行环境，各种参数和处理逻辑。但是这个时候也只是 “被注入”了而已，程序还没运行。
然后一系列的链式 Middleware 一层一层的引用封装。
这个时候 Middleware 垂直体系已经建立。wsgiapp 完成。但是还没有run。
3、run
所有的python框架再怎么变化，最后都要有这么一个轮回，app毕竟只是app，它要在服务容器中运行。
当然，这外部容器五花八门，这里不是重点，不多讲，wsgi app的命运是要被外部 调用的。
app 的 __call__(self, environ, start_response) 方法被调用。
刚才说，app 外面包了很多层的 Middleware ，所以这个按 “ 先进后出 ” 的方式 一层一层调用。
Middleware 调用到最后，到最底层 PylonsApp 里面的 __call__，又一个关键点
controller = self.resolve(environ, start_response)
Controller 诞生。根据信息，找到 调用的 Controller
下一步
response = self.dispatch(controller, environ, start_response)
调用 Controller 产生 response ，
然后再一层一层 由外部的 Middleware 再对 response 处理。
所以，这里 Controller 在整个体系的只占很小一部分，也是pylons 让用户去写逻辑的一部分。
所以各种应用，各种形式的 只要满足 wsgi 都可以在pylons 上跑，因为pylons 已经把逻辑抽离出来了。
对 Pyamf 的困惑也游刃而解，Pyamf 对 pylons 的支持 只不过 按照自己的需要 定制了一个 自己的 Controller
而已， pylons 的众多特性已经在使用当中。
感受到此结束，enjoy ！！