@lengyihan git 地址是明文。

@ericgui 不是没有优质内容，是垃圾信息太多了。全世界的垃圾信息都在不断增多。

在国内的微信公众号这种狗屎平台一出，很多程序员又把优质文章丢进去不放出来给那些复制号去抓。

一增一减，就感觉中文优质内容彻底没了。

请不要侮辱实习生……

说实话，我是真的羡慕尤雨溪的运营能力。Vue 这框架，你说技术牛逼吧，其实刚火起来的时候也不算那么好。但是运营能力吊打任何国产框架，造就了世界一流的前端框架。

纯技术要走出来，太难了。

这，其实如果不是大厂你完全没必要考虑这一点的。什么每日调用千万次这种小流量的服务，你用啥都差不多。基本上有一个长连接（比如 http1.1 或者 http2.0 ）就可以了。之前为了自家业务随手写了一个 git.io/rpc.py 框架，一天几十万次调用，我连优化都懒得做，http1.0 莽就完事了。

记不清含义的可以这么记：登录这个操作，是登记、录入的意思；登陆，顾名思义，是登上某片大陆，可以引申为登陆市场。

@neoblackcap 说实话，Python 这种动态语言，就没有哪个神仙靠纯推导搞出好用的代码提示。一旦好用，针对特定情况直接穷举的脏活必然存在。

没有。Django 太流行，以至于 PyCharm 直接针对它的 ORM 开发一套推导程序。

说实话，不是我看不起开源社区。这种东西，大公司领先开源社区起码十年，毕竟 KPI 压着和靠爱发电，前者相对更靠谱。

@lijialong1313 。。。那必然是不行，不过 Python 社区有一个项目可以把 Python 和 html 混着写。那个再配上这个文件映射 URL，就有 PHP 那味儿了。

@8520ccc 纯属娱乐。。。

哈哈哈。文件映射方式啊。文件是什么路径，对应的 URL 就是啥。
@Patrick95
@wellsc
@wysnylc

@Rwing 说的如果不是 no message 会有人去看一样。

@haoliang flask 的起因是因为和 bottle 有分歧，照你的意思 flask 就应该做一个纯粹的 WSGI 工具包咯？

你不一定写过这种微型 web 框架，那我把之前解释过的问题再解释一遍：路由系统是一个微型 web 框架最重要的支柱，它负责分配路由、调用中间件、解析路径参数种种支柱功能，一个微型 web 框架的灵魂就只在于路由系统。如果把 starlette 的路由替换成前缀树，那其实就是另一个 index.py ，没差别。

Index.py 的 request 和 response 对象都保持了 starlette 优秀的设计，你不妨试试。

应用场景都不一样，Python 为啥要和 Java 斗？

@fy 巧了。。我也发了一封邮件给你的 GitHub 上写的邮箱。已经回你发给我的那封了。

@fy 行啊。

@fy Index.py 的设计上是只考虑纯 Python 的，所以暂时不会考虑这一类优化。不过如果特定用户有需求，可以通过替换 `app.router.http_tree` 属性来做。Index.py 里大部分地方都是这样可以替换的设计。

@fy 你这个 DBView 思路很有意思啊。不过现在好像除了 restful，比较流行的就是 graphql，感觉你这个如果能增加自动生成数据库的 graphql 接口会有很有趣。graphql -> SQL 。

路由的话，本来我之前是做的类似于 php 那个文件系统映射的，这个 Radix Tree 纯属是我和 starlette 谈崩了的产物。然后发现如果我先实现 Radix Tree，再实现我朋友给我提的 pr，也就是带路径参数的文件路由会比较简单。虽然这个文件路由跳票很久了……我个人感觉 web 框架要解决的最重要的问题其实就是路由，其他的反而好解决。因为可以让用户自己写。而路由系统是灵魂，由它来把请求和中间件、视图函数连接起来。这一部分做好了，其他部分就是堆代码优化用户体验的事了。而且目前 Python web 框架之间的路由寻找的差距会很明显……你看我的 benchmark 。不像 golang，一水的前缀树，速度完全是比拼其他部分了

@Mitt 感觉还是大环境问题，国外活的好的开源项目都有公司长久捐款，等于是商业公司养着他们专职做开源，然后商业公司再用这些项目去开发、赚钱。国内目前没有这个环境……小公司不舍得花钱，大公司要求“自主研发可控”。