API方式不适合传统的页面。

以V2EX为例，显示一个首页，你需要调用首页主题、当前用户信息、社区运行状态、最热节点、最新节点、最近访问节点和节点导航等API，如果你不是异步调用这些API的话，网络延迟足够让你的用户抓狂了。

如果弄成AJAX，或者facebook的BigPipe，用户就不会感觉被拖慢了，但这明显会让你的应用变复杂。

二次开发明显Discuz!好于PHPWind，结构更加分明，模板和插件数量与后者相比是数量级的优势。

性能说实话我没感觉出什么差异，老版本似乎是PHPWind更快，但较新的版本好像被Discuz!反超了。

管理方面Discuz!最初的配置比较麻烦，而且要找个功能简直像大海捞针。PHPWind这方面上手很快，可以减少很多体力劳动。

容器设为position:relative，要定位的元素设为position:absolute，然后用bottom定位。

回复真多，插句嘴：我认为短而直观的实现总是更为优雅。Python中提供了这个功能，如果你认为用它实现最简单，就不要怀疑地去使用它。

例如我在YUI里就用了getattr：
https://bitbucket.org/keakon/yui/src/4adaf38a3581/yui.py#cl-1272

web.py也用了这种方法：
https://github.com/webpy/webpy/blob/master/web/application.py#L633

否则得像webapp一样写很多if..else：
http://code.google.com/p/googleappengine/source/browse/trunk/python/google/appengine/ext/webapp/__init__.py?r=142#514

metaclass和decorator我一般只用来隐藏实现，让使用者无需关注其内部的实现。而现在的问题是你开放的这些接口本来就是用来调用的，不应该由被调用者强行注入调用者。
这也是我觉得用decorator来标记一个handler的不妥之处：传统的url mapping方式你可以很一目了然地知道哪些url映射到哪个handler了；而像Uliweb那样写个@expose的话，你得找到所有的handler才能确定这些映射关系，并且还得关注handler的定义顺序和import的顺序。
而这一切并没有带给你任何好处：逻辑更复杂了，阅读更困难了，维护更吃力了。


最后说下那个help的例子，你不觉得使用decorator的实现导致help函数与其他函数之间的耦合度增加了么？
明明其他函数已经开放了__doc__这个属性了，却还要强迫它们维护help函数所需的_actions列表。

如果定义一个Helper类，遍历自身的方法，用getattr取它们的__doc__，就可以少写一个函数、一个列表和多处@action。并且，如果这个类被继承了的话，扩展它的人也不需要写@action来保证help()仍能正常工作。假如你哪天觉得action这个名字不好，需要重命名时，也不需要各处去查找替换@action。

当然，这个例子如果用metaclass实现的话耦合度没有这么高。但在继承时如果不想展示子类的某几个方法，却发现子类的metaclass必须继承父类的metaclass；而如果有多重继承和多个元类则会更复杂。
虽然这种情况很极端，但你不觉得元类会把实现变得更加抽象么？回过头来想想，它本来不是个很简单的反射就直截了当能完成的事么？

头一次看到拿字符串比较的，提醒一下：'2' > '1001'

更新缓存很麻烦，而且很多浏览器的提示很蛋疼，好像被攻击了一样…

我觉得是gears退化后的产物…

try: f = getattr('funcname')
except AttributeError: ...
else: f(*args)

但是不需要全屏吧，很多网页大了不好看

@myrual bitbucket对于5人以下的项目（包括私有项目）免费，无空间限制

泪流满面的神器，就是稍微贵了点。Guido因为是在做开源项目，所以可以申请open source project license的。

刚才在GAE论坛也看到了。楼上别好奇了，作者是大名鼎鼎的Guido van Rossum啊，Python的作者，Google的员工。

SDK版本升级到1.3.8以上再说

我测试得和你正好相反：

from timeit import Timer
print Timer('''a=None
if a:pass''').timeit(0xffffff)
print Timer('''a=None
if a is None:pass''').timeit(0xffffff)

前者明显快：
0.599301028483
0.708215988345

而且我执行了1千多万次，相差也只有0.1秒左右，很难相信是它造成的性能瓶颈。

再看字节码，前者是：
0 LOAD_CONST 0 (None)
3 STORE_FAST 0 (a)
6 LOAD_FAST 0 (a)
9 JUMP_IF_FALSE 4 (to 16)

后者是：
0 LOAD_CONST 0 (None)
3 STORE_FAST 0 (a)
6 LOAD_FAST 0 (a)
9 LOAD_CONST 0 (None)
12 COMPARE_OP 8 (is)
15 JUMP_IF_FALSE 4 (to 22)

明显前者少执行了2条语句，没有理由更慢

@reus 首先确认你问的是不是这个： http://wiki.php.net/rfc/traits

粗略看了下，类似于Ruby的mixin。

A Trait is a unit of reuse much like a class, but only intended to group functionality in a fine-grained and consistent way.
Python是支持多继承的，所以没有traits。

简单来说，这个问题好比拿了台手机，然后问别人你的电脑键盘可以敲3下2打出个c么？