delayrun 并没有被嵌套调用, 只是作为 Timer 的回调, 你这段代码的作用实际相当于一个 loop:

while 1:
sleep(timer_i)
print "running..."

还是无法编译, 错误如下:

D:\tbox>xmake
compiling.r src\tbox\tbox.c
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
Stop.

cl : Command line warning D9002 : ignoring unknown option '-arch:SSE3'
cl : Command line warning D9002 : ignoring unknown option '-arch:SSSE3'
cl : Command line warning D9002 : ignoring unknown option '-arch:MMX'
tbox.c
d:\tbox\src\tbox\asio\aice.h(446): error C2220: warning treated as error - no 'o
bject' file generated
d:\tbox\src\tbox\asio\aice.h(446): warning C4359: '__tb_aice_t::<unnamed-tag>':
Alignment specifier is less than actual alignment (8), and will be ignored.
error: build target: all failed!

上面出错的原因, 补充下:
好像是 xmake 安装目录中有空格造成的, 比如默认的:c:\Program Files\xmake

编译 tbox 出错. 环境:windows7, msvc2015, xmake(自己修改了下, 加了 2015 支持)

D:\tbox>xmake
compiling.r src\tbox\tbox.c
'xmake' 不是内部或外部命令，也不是可运行的程序
或批处理文件。
NMAKE : fatal error U1077: 'xmake' : return code '0x1'
Stop.

error: build target: all failed!

看了 Why-does-Google-prefer-the-Java-stack-for-its-products-instead-of-Python:
里面提到的 python 缺点实际只有两点 Concurrency 和 Performance(完全没有提动态类型这些), 而两点实际就是性能问题, 而性能问题就是因为 GIL, 而现实中需要大量占用 cpu 的应用并不多(支付模块中应该不会存在这类问题).

如果改得地方不多, 可以这样:
先 git clone 下来, 然后直接修改代码, 修改完后生成 patch(git diff > patch).

以后更新执行下面的命令就可以了:
git reset --hard HEAD
git pull
git apply patch
rm -rf build
rm -rf dist
python setup.py install

感觉是基于 chrome 的 UI 修改的, 比如说 tab 拖放感觉就跟 chrome 表现的一样.

可以用 systemjs:
https://github.com/systemjs/systemjs

不过建议通过 jspm 来用 systemjs:
http://jspm.io/

升级到 python2.7.10

这样的情况一般都是 gbk 被当成 utf-8 decode 了.

应该使用:
import locale
locale.getdefaultlocale ()[1]

@Feiox
我觉得抽象层会让以后添加新功能很麻烦（因为新功能一般需要改动底层的东西），还有就是抽象层多了 call stack 会很深，对于代码的非原作者了解代码很费时间（因为大部分情况除了看 API 的文档外，还要看源代码才能理解这个函数的具体作用）。我觉得这篇 blog 的观念很好： http://www.yinwang.org/blog-cn/2015/06/14/dry-principle/

对于代码的复用我觉得 reactjs 里面的 component specs 的方式就比 subclass 的好， component 定义的任何变量或方法都不会跟父类冲突，父类决定了那些方法能被子 component override ，那些是被 chained call 等.

一般魔幻的东西会隐藏很多内部的 call ，这一点我觉得有背于 explicit is better than implicit 。比如 with 的作用大部分相当于 try finally ，我宁愿直接用 try finally 。大部分 OOP 语言的 this 也是，而 python 里的 self 就比 this 灵活得多。

问题 1. 可以参考: https://github.com/geertj/gruvi/blob/master/lib/gruvi/util.py#L52 其中的 wrap 函数。

不要用继承来当接口，不要有很多的抽象层

内部实现尽量扁平化，方便debug，方便测试

如果能确认被del的没有在其他地方被引用的话, 先清理缓存后再gc:
import sys, gc
sys._clear_type_cache()
gc.collect()

全部分析的话应该不可能, 工具最多只能把有raise的地方找出来.

ctypes可能会segfault, 你为什么不在debugger下运行python

@oott123 可以让别人看不懂你的代码

一直不明白, 为什么不直接用greenlet