无知的 tonyseek

Yet Another Seeker

Python 描述符(descriptor) 杂记

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

关于 Git 工作流的随笔

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

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

胡思乱想:封装到底是什么

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

慎用异步 WSGI Server 运行 Flask 应用

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

写了一个 RBAC 权限管理工具

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

在 Flask 里产生流式响应

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

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

让 Web 控制器更有条理

这里的“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 框架 Flask 的一些个人评价

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

用 greenlet 协程处理异步事件

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