带宽是不是都爆炸了 ？

开发就喜欢瞎几把编译

php 死于 fast cgi,真正的“脚本”思维语言

现在都开始依赖常驻进程了,那么多年来没有任何常驻进程相关的库积累,以前的框架都不是照常驻进程设计的,导致大量 php 程序员都没有相关知识

脚本语言里也就 php 有这个缺点

如果用 php 这个缺陷不是大问题的确没必要换

要加上定语 MYSQL

其他数据库 uuid 似乎没问题哦 哈哈哈
更别说时间序的 uuid 了

制表符靠谱 python 就不会用 4 空格了
制表符不靠谱又不是 python 的锅

无论什么语言写对齐都要算字符宽度然后填充空格
中文字符宽度还要麻烦一点

去参考 prettytable 怎么写的

抄 openstack

处理 key generator

args = compat.inspect_getargspec(fn)
has_self = args[0] and args[0][0] in ('self', 'cls')
if has_self:
args = args[1:]


或者直接用 dogpile

哼！ php 能 7 得, 我 python 就不能 8 ？

看那么多书后你写了多少行代码呀？

至少之前我看 kombu 代码的时候还不支持 asyncio

asyncio 就在大量库支持之前根本没法用,还不如老老实实 eventlet

好好学习下写守护进程和要命了一样

WINHEX 用二进制打开文件对比你就知道什么问题了

瞎猜个什么劲

重启命令加到 sudo 里

请用笔记本加扩展坞
家里放显卡坞

嘿嘿嘿

在 pool 代码里加日志

从 pool 里取出 connection 的时候打印一条
还回去的时候打印一条

这不就知道哪次没还回去了么？

打日志打日志打日志

@pinews

a=1&b=2 不一定要看作 form 表单, 服务器端也可以认为是 filter

按现在的流行 a=1&b=2 作为 filter,具体数据在 body 里以 json 存放

没有区别, 有区别的是服务端根据 rfc 标准如何处理,以及客户端（库）是如何处理的

a=1&b=2 可以在 url 后面,也可以在 body 里.
到底是在 url 里还是在 body 需要看客户端代码如何处理的
如果在 url 里还会受到服务器端包头长度限制的影响

put 和 post 最大区别在于 post 可以提交多个字段的内容，多个字段内容用&或者随机字符边界分割。


没有这个区别