Flask 2.0 版本发布

[greyli]

包括 Flask 在内，6 个 Pallets 项目都在今天发布了新的主版本：

• Flask 2.0
• Werkzeug 2.0
• Jinja 3.0
• Click 8.0
• ItsDangerous 2.0
• MarkupSafe 2.0

欢迎更新试用：

pip install -U flask

Flask 2.0 新特性介绍： https://greyli.com/flask2/

[frostming]

@yxt Flask 通用性不仅是写 HTML 模板差异，通用的意义在于不预设任何东西，你有更多自定义的空间同时也带来更多编码的负担。

FastAPI 在此基础上添加了「它认为好用」的数据验证和序列化（ pydantic ）和自动的 API 文档生成，从用户角度上来说当然负担小容易用。

但显然它俩并列比较*不公平*，这是 greyli 文章的意思

[frostming]

这是两个项目根本愿景的不同，你说 Flask 改进不足，Flask 现在没有，将来也不可能，集成一个像 pydantic 这样的库进来，它们解决的目标问题本来就是不同的

[greyli]

@yxt 关于观点 1 、2 、3，也就是能不能比较的问题，我的观点都在文章里表达的差不多了，再重复也没有什么意义，@frostming 也补充了一些解释。我完全接受你不认同我的观点，你可以写一篇《我认为 Flask 和 FastAPI 可以放到一起比较》，我会把文章附到结尾供读者参考。

唯一想要补充的是，如果你读过 FastAPI 的文档，那么在 Benchmarks 这一章（不太清楚为什么放到这里）有一段已经说明了关于「比较」的问题：

> If you are comparing FastAPI, compare it against a web application framework (or set of tools) that provides data validation, serialization and documentation, like Flask-apispec, NestJS, Molten, etc. Frameworks with integrated automatic data validation, serialization and documentation.

https://fastapi.tiangolo.com/benchmarks/

简单翻译如下：如果你在比较 FastAPI，把它和提供数据验证、序列化和文档的 Web 框架（或工具集合）进行比较，比如 Flask-apispec 、NestJS 、Molten 等等；把它和集成了自动化数据验证、序列化和文档的框架进行比较。

我想这是不是可以理解为 FastAPI 作者也认为 FastAPI 不能和 Flask 一起比较呢？这或许能够稍微改变你的看法。

观点 4 、5 、6 晚点回复，去吃早饭了。

[Latin]

请不要抨击 Flask 了，只要是框架自己用的舒服就行，不要以类比的姿态来抨击和贬低它。

[greyli]

@yxt

> 4. 再说这个靶子, 原文写了 FastAPI 写法简洁的优势, 如果 APIFlask 可以做到类似的事情, 为何不正好 show 一下以论述 "简洁的写法并不是 FastAPI 所独有的"? 我感觉 marshmallow 并没有 pydantic 好用.

我在那篇文章里没找到我表达过「 FastAPI 写法简洁」、「简洁的写法并不是 FastAPI 所独有的」这些观点。建议后续讨论原文引用。

介绍 APIFlask 并不是那篇文章的主题，如果读者感兴趣的话，自然会点进对应的链接去了解 APIFlask 。我提及 APIFlask 是因为它是基于 Flask 的扩展和框架里唯一和 FastAPI 对等的比较对象（欢迎不同观点），而不是为了推广它而强行加进去。不过仅仅这样都让你认为我的主题是「"既然看到了 FastAPI, 也来看看 APIFlask 这个新项目"」，那我要是像你说的「正好 show 一下」，估计你就要认为这是 100% APIFlask 软文了吧……

至于 Marshmallow 和 Pydantic 哪个好用，见仁见智，我对 Pydantic 不够熟悉，没法提供更多观点。

我也一直想深入对比一下用 FastAPI 和 APIFlask 的各种写法的不同，但是一来没有时间，二来对 FastAPI 还不够熟悉，所以目前的对比仅限于一些基本特征，详见 https://apiflask.com/comparison/#apiflask-vs-fastapi 。

附注那篇文章（《请不要把 Flask 和 FastAPI 放到一起比较》）的链接供后来者参考：

https://greyli.com/flask-fastapi/

[greyli]

@yxt

> 5. FastAPI 的推介者没有义务一定要从 FastAPI 是基于 Starlette 和 pydantic 的一个衍生框架这个角度来介绍, 开发者也没有义务一定要把这句话放在第一句, 技术背景放在 requirements 里很正常, 又不是刻意隐藏;

同样，我那篇文章里也没有说过推介者和开发者有义务怎么样、技术背景放在 requirements 里不正常在刻意隐藏。我只是在论述引起错误对比的三个原因。建议反驳观点时原文引用。


> 6. PR 里大量的文档翻译工作作为用户是喜闻乐见的(虽然我是看英文的), 虽然从开发角度看的确比较停滞.

用户要看的是翻译结果，而不是「 PR 里大量的文档翻译工作」，把翻译放到单独的仓库或是用翻译平台协作会是对用户和开发者都更友好的方式。

[abersheeran]

@yxt
@frostming
@greyli

我用一个我觉得还算恰当的比较来说吧：fastapi 就是用依赖注入把 starlette 和 pydantic 拼接起来了，Web 部分它完全使用了 starlette，只有微小的增改。如果我说 django-restframework 是一个 Web 框架，大家的想法是？如果 fastapi 算 Web 框架，那么 django-restframework 也得算 Web 框架，django-simple-api 也得算 Web 框架，django-ninja 也得算 Web 框架，APIFlask 也得算 Web 框架。

觉得 fastapi 算 Web 框架的可以去看看我提到的这几个项目。

[abersheeran]

这事说到底就是知道 fastapi 怎么做出来的人和不知道的人的认知矛盾（这一点还得怪 fastapi 的夸张营销，骗了不少人）。

知道的人：fastapi 是 starlette+pydantic 拼起来的，最多只能算 starlette 这个 Web 框架生态中的一个组件
不知道的人：fastapi 是一个可以拿来开发 API 的 Web 框架

[frostming]

用户这么认为没问题，他用上 FastAPI 觉得爽抛弃了 Flask 也没问题，但推介者不能对比两者后得出 Flask 差的结论。两个项目各取所需，求租者当然喜欢拎包入住，但你不能说毛坯房不行，自有需要自己装修的人会买。

[mansurx]

生产环境还在用 0.12.0 😅 还需要多向大佬学习

[l4ever]

好家伙, 我看到你了, 在官网
https://palletsprojects.com/people/greyli/

加油, 好家伙, 我在用 Flask.

[yxt]

@abersheeran
@frostming
@greyli

首先向各位开源大佬问个好 :) 技术上向各位学习, 这儿仅就 @greyli 的文章的观点讨论一二.

关于项目愿景, 定位和技术定位, 严格上说的确 FastAPI 和 Flask 不完全对应, 理解各位这个思考问题的角度.

我的角度更偏用户:

- 用户用的是谁的 API, 就是在用哪个"框架", FastAPI 在 starlette 上包了一层, 用户没有直接用 starlette, 就说明这层包装有意义 (或, 最终发现无意义而弃之), 没必要去强调依赖关系, 技术上的核心和用户的感知不一定是统一的 (此处 @abersheeran );
- 用户基于流行程度 /成熟程度的比较是很自然的逻辑: 先筛选流行 /成熟的, 再对照看有没有满足自身需求. 首先判断两者是否等价, 是否直接可比? 不太可能吧.
- opinionated 和通用性是中性的, 无视趋势的通用性和过于小众的偏见都会损失用户. FastAPI 的流行说明它的确解决了一些用户痛点, 代表了相当一部分用户的实际需求.
- 假定 FastAPI 的方向是"正确"的, 如果 Flask 选择目前的定位, 那这样的比较和用户的流失是会长期存在的, 直到 FastAPI 更为流行, 两方的用户能够明确地"各取所需"为止. (此处 @frostming )

再提两句 @greyli 的原文, 我的核心意见, 还是"从用户角度, Flask 和 FastAPI 并不是不可比的":

- 首先说文中的靶子, 该文描述了 FastAPI 在编写 API 场景相对 Flask 的写法优势, 逻辑我认为是自洽的. 文中写: "你确定你用了四年的是 Flask 而不是 Flash ？" 难道, 在使用 Flask 编写 API 时, 并不是这样的吗?
- @greyli 认为两者虽然都很流行, 但是定位不同不能直接比较. 理论上这是对的, 但我认为是没什么意义的, 流行程度本就是非常重要的筛选器;
- 框架仅用于编写 API, 应该可以代表大部分使用者的场景(欢迎指正). FastAPI 的流行也印证了这一点;
- 文中提到的 FastAPI 的问题的确存在, 但次要. 文中提的文档中的"「大胆」的措辞和承诺以及不厌其烦的特性介绍", 这个不厌其烦, 怕是把各种推介者的搬运算上了吧? 一个精心设计的 readme 并不是负分项.

以及对 APIFlask 的推介:

- 非常赞同作者对自己心血的推介, 只是窃以为在此文中显得不太合适;
- 窃以为 marshmallow 不如 pydantic, 待 @greyli 了解评价一下.

最后是 @greyli 的一些答复:

> 我在那篇文章里没找到我表达过「 FastAPI 写法简洁」、「简洁的写法并不是 FastAPI 所独有的」这些观点

"FastAPI 写法简洁"是靶子文所表达的, "简洁的写法并不是 FastAPI 所独有的" 是我提议的如果想树立靶子, 则可以考虑论述的一个方向;

> Benchmarks

不反对技术层面对比的一致性要求.

[ragnaroks]

对比这个事让我想到 Vue 和 JavaScript 的对比了，这个可就真的是腥风血雨了

[abersheeran]

@yxt 好家伙，你说没“直接用到” starlette ？我现在怀疑你连 fastapi 都没怎么用过吧。但凡你从头到尾看过一遍文档，写过一点代码，from starlette ... import ...； from pydantic import ... 你肯定就写过。

[abersheeran]

@yxt 那我概括一下你对我的回复，你的观点是：django-restframework 是一个用来写 API 的 Python Web 框架。那么同样的，其他几个项目也都是 Web 框架。 @greyli 看来你的 APIFlask 可以对外宣传说自己是 Web 框架了😀

这个话题就没什么可说的了。你既然认为它们都是 Web 框架，那么自然可以互相比较。哪个好用就看个人喜好了。

[yxt]

@abersheeran
这 虽然暴露了依赖的细节 但我大部分时间还是对着 fastapi 的文档写呀 我直接面对的并不是 starlette 以及我虽然没使用异步，一整个项目还是做下来过的
大意如此，我不会因为依赖关系而区别对待

[WilliamYang]

@yxt 认同你的观点，用户一开始并不会也不需要考虑依赖关系，而是选择合适他们，而又“好用的”框架

[opentrade]

玩了一下很失望，我的场景是有一个 api 需要用到异步等待，某些请求需要 await asyncio.sleep, 结果经常出现 bad gateway，考虑到 nginx timeout 时间，我调小 sleep 时间，消除了 bad gateway，可是有时无需 sleep 的请求依然会慢，害得我不得不放弃异步，在外面包了一层 golang 。

[RRRoger]

看过大佬的书 牛皮