@PythonAnswer django 肯定是活得最长的 python 的 web 框架啊，想什么呢？

当然挺大 asyncio
asyncio 是标准库你们想什么呢，关于异步相关的操作和规范都朝着 asyncio 制定的， tornado 等其他框架只能效仿，没出来前 gevent tornado 什么的各搞各的， asyncio 作为标准库这是 python 异步 IO 的官方范本，楼上说的什么 tornado 也可以用 asyncio 啥的，这是把 tornado 当成纯粹的应用层的框架了吧，这个 tornado 毫无优势啊。

异步的数据库驱动坑多收益少，不如直接线程池，访问密集的地方，你真的会直接敢把流量打到数据库上吗？考虑异步数据库驱动的你真的需要吗？

“我思考了半天我有什么想学习的，很不幸的，脑子空空如也，什么也没有。。然后就是各种迷茫。。。 ”

好生动的场景

233 当年想申一下 NTU 的 MS 后来还是去工作了

程序媛就已经秒杀一切了。

难道是 65daigou ？

@mathgl django 做 db schema/admin 以及和一些其他的东西比如 es mq 类的部件 等等， tornado 做 api

@cjyang1128 是的，如果 select for update 语句放在一个比较大的事务里，经常会发生死锁 /

几万条都是小数据，没必要优化

搞笑的协议吧。

对给定文章，评论表自增 id 最大和“最新”是否是一个意思？ （前提是有自增 id 而不是 uuid 。。）

@dlllcs 千万不要用 wkhtmltopdf ！！这货坑出 shi 来了，内存泄露横跨所有版本，不限制内存的话经常系统直接被这个拖挂

有个东西叫 phantomjs ，有个东西叫`reaterize.js`

代码见 https://discuss.erpnext.com/t/replace-wkhtmltopdf-to-phantomjs/14674/4

@mathgl tornado+django 倒是非常常见，但是 flask 有点格格不入

@t123yh
现在的问题是，要多快？现有的速度是否无法接受？
如果还没达到量级建议暂时不要考虑优化问题，良结构的方案都会相对来说慢，但是如果不需要，还是不要放弃良好的结构比较好。

@cjyang1128 计数器场景的话建议不要使用 select for update ，我们在这上面被坑出 shi 来了，不如直接用 REDIS 的 INC 操作。

pytest 是 python 做 unittest 的首选框架，以及，你用 pycharm 创建 unittest 的方式错了， tests 目录需要自己建，单元测试的文件放在这个目录下，命名 test_UNIT.py 。

@des 上学的时候我觉得 良范式化的结构设计可以在很多场景下一次把数据查出来

后来工作了发现 bullshit ，很多时候都要异构查询