Python 引入的“描述符”(descriptor)语法特性真的很黄很暴力，我觉得这算是 Python 对象模型的核心成员之一。Python 语言设计的紧凑很大程度上得益于它。所以写一篇笔记文记录关于描述符我知道的一切。

关于 Git 工作流，我之前只知道有个 Git Flow。工具我没有用过，不过思路我很赞同。类似 Git 这样的分布式版本控制，不再强调代码在提交时的整合，而是强调中心库向私有库的分裂和各个私有库各自的合并。分支越细致，合并代码的成本就越低。以 Feature、Bugfix 为单位整理分支，合并的时候就会非常清晰。如果代码耦合度低的话，几乎所有合并都可以自动完成。

这次在学校和同学一起开了一个 Web 项目，代码用 Git 来管理。参与的同学之前只用过 SVN，对 Git 也是初次接触。我考虑要不要尝试一下 Git Flow 这个工具，所以在豆瓣发了一条广播，结果几位同学回复让我看到更多类似 Git Flow 的工具或者思路，所以写篇文章记录下。本文纯属记录，没有主题。

最近比较忙，奇怪的是越忙的时候就越会有一些很无聊的胡思乱想。想到了一个初学面向对象时被问到烂了的问题：封装到底是什么。这个问题课本有标准答案式的解答，什么隐藏内部实现保留外部接口，但我并不满意这个回答。今天上课的时候又被老师的关联话题提起，于是想记录一下我现在的想法。

这个标题有点不太准确，其实应该说：慎用异步 WSGI Server 运行基于 Werkzeug 的应用。或者更宽泛一点——慎用异步 WSGI Server 运行使用 Thread Local 的应用。 Flask 是基于 Werkzeug 的故也在此列。貌似使用 Werkzeug 作为底层 WSGI 库的框架还有国内 limodou 老师的 Uliweb 。而其他使用 Thread Local 的 WSGI Application 不计其数，Bottle、web.py 都在此列。但我没有测试过其他的，仅仅掉下过 Flask 的坑。

前几天在邮件列表看到大家在说有没有好用的权限管理工具，有人说 Zend_Acl 不错。我看了下官网文档，貌似是挺不错的，用起来很方便。可惜 Zend_Acl 是 PHP 的，我于是兴起模仿它的用法，写了一个 Python 版的。

用过 Bottle [0] 的同学应该不会忘记它的流式响应 [1] ——在视图函数中使用 yield 关键字，让调用结果成为一个迭代器，那么 HTTP 客户端将会得到这个迭代器每次迭代的结果一部分，迭代器产生多少客户端收到多少，就像流一样。用这种方法在产生一些大的响应对象时（比如大文件下载），能有效地节约服务器内存。

运行以下代码并在浏览器访问 http://localhost:5000/stream

说来惭愧，听说 控制反转（Inversion of Control） 和 依赖注入（Dependency Injection） 这两个名词已经是大二的事情了，时至今日才想明白了具体的含义。我之前知道依赖注入的用法，一直将控制反转将其等同化，现在看来二者其实还是存在差别的。于是今天就此也顺便查阅了一些资料，将一些思考记录下来。

这里的“Web 控制器”指的的确是 MVC 中的 Controller，在 Django 等 Python Web 框架中也被称为“视图”。

说到本文，源起 Python Web 框架中对于“控制器”有两种不同的表达方法。其中一种是类似于 Rails 的 class-based，另一种是 类似于 Sinatra 的 function-based（当然 Sinatra 的实际是 block-based）。tornado、web.py 采取了前者，而 Flask、Bottle、Django 采取了后者。

在组织简单代码的时候，两种方式仅仅是风格上的区别，这时候往往 function-based 会显得更加简洁。但对于更加复杂一点的情况，class-based 的控制器有一些代码组织上的优势，可能 function-based 的需要花一些脑筋才能达到相同效果。

Python 多到数不过来的 Web 框架已经成为了一大风景，而且不同于 PHP Frameworks 集体山寨 Rails 的风格，几乎每个 Python 框架都有自己的特色。我接触过的有 web.py、Django、Bottle、Flask ，其中属 Flask 最为我喜欢。有时候框架会被称为“轮子”，但是可以确定的一点是这四个框架一定不是轮子，我最喜欢的 Flask 有许多非常方便的特性，当然也有我想吐槽的不爽点。于是写一篇博客把吐槽记录下来。

自从 PyCon 2011 协程成为热点话题以来，我一直对此有着浓厚的兴趣。为了异步，我们曾使用多线程编程。然而线程在有着 GIL 的 Python 中带来的性能瓶颈和多线程编程的高出错风险，“协程 + 多进程”的组合渐渐被认为是未来发展的方向。技术容易更新，思维转变却需要一个过渡。我之前在异步事件处理方面已经习惯了回调 + 多线程的思维方式，转换到协程还非常的不适应。这几天我非常艰难地查阅了一些资料并思考，得出了一个可能并不可靠的总结。尽管这个总结的可靠性很值得怀疑，但是我还是决定记录下来，因为我觉得既然是学习者，就不应该怕无知。如果读者发现我的看法有偏差并指出来，我将非常感激。