Flask 2.0 版本发布

39 条回复 • 2021-05-19 11:20:20 +08:00

1

ice2016

2021-05-12 14:12:46 +08:00

看看新版本··

2

janxin

2021-05-12 14:24:04 +08:00

赞👍

3

misaka19000

2021-05-12 14:26:06 +08:00

哇，奈斯

4

xiaomingVTEX

2021-05-12 14:28:43 +08:00

新路由挺好

5

abersheeran

2021-05-12 14:29:28 +08:00

4

看到 Flask 都 2.0 了，我想起来一个有意思的事，Flask 从 0.x 到 1.0 用了许多年，Django 从 1.x 到 2.0 用了许多年。然后 Flask 从 1.0 到 2.0 几乎就是一瞬间（我现在还能记得那时我还是个仰望所有开源项目的小菜鸟，许多人不断地说着 Flask 终于 1.0 了），Django 从 2.0 到 3.0 也几乎是一瞬间（我学习的时候还在 1.11 ，然后突然某天群里有人说 Django 发布 2.0 了）

Web 技术好像一直在变，又好像一直没变。

算算我学 Python 快四年了，四年如一梦。Flask 0.x 到 2.0，Django 从 1.11 到 3.x 。

人老了，总是怀念过去。肆意狷狂、叱天呵地的日子又能过多久？

6

wellsc

2021-05-12 14:33:03 +08:00

当年入行的时候全靠 0.1x

7

onbeam

2021-05-12 14:34:21 +08:00

刚看到大佬出的 flask 书

8

CallMeReznov

2021-05-12 14:38:49 +08:00

阿里云的镜像还没更新还是 1.1.2
jinja 到是 3.0

用官方源更新过去了

9

chenqh

2021-05-12 15:09:12 +08:00

我还在用 tornado,套

10

zhengdai1990

2021-05-12 15:10:33 +08:00

fastapi 据说比它好？

11

maobukui

2021-05-12 16:07:39 +08:00

1

@zhengdai1990

"请不要把 Flask 和 FastAPI 放到一起比较"
"如果看到有人把 Flask 和 FastAPI 放到一起比较，请把这篇文章的链接丢过去。"
https://greyli.com/flask-fastapi/

12

greyli

OP

2021-05-12 16:38:56 +08:00

@maobukui 哈哈，谢谢。我刚想发链接……

13

olddog5172

2021-05-12 17:28:00 +08:00

大佬的网站怎么打不开了

14

johnsona

2021-05-12 17:32:38 +08:00 via iPhone

那个加载任意配置的感觉可以

15

Kilerd

2021-05-12 18:29:17 +08:00

不管如何对比，我觉得 fastAPI 用的那套 PyDynamic 用了实在是回不去了。

16

abersheeran

2021-05-12 21:49:17 +08:00 via Android

@Kilerd 那玩意你可以在任何框架里实现出来，代码量很小。我写了一个 Index.py ，后来又在 Django 上实现了一遍。全都是在线上跑的代码。

17

greyli

OP

2021-05-12 22:41:54 +08:00

@olddog5172 似乎是你所在地区的网络问题？

18

yxt

2021-05-13 00:34:37 +08:00

4

作为一个 FastAPI 用得还算开心的用户, 并不苟同"如果看到有人把 Flask 和 FastAPI 放到一起比较，请把这篇文章的链接丢过去" (当然发那个帖子里比较合适, 顺手就发这儿了):

1. 如果用户本意就是要在流行的框架间比较呢? 从"流行的 python 框架" 角度出发, 一起比较并无不妥, 没必要理清楚衍生关系(基于某框架的某框架), 而从衍生关系出发, 把两个(至少是当下)流行程度和成熟程度不在一个量级的框架放一起比较, 反而怪怪的.

2. 强行区分 Flask 和 FastAPI 的一个前提, 就是 Flask 更"通用". 一方面, 从需求上说, 前后端分离的趋势下, 强调这么一点写 HTML 模板的能力的差异而强行说两者不能比较有点不妥, 另一方面, FastAPI 又不是不能用 template engine. 或者说, 这个 Flask 额外具备的通用性, 还有别的含义?

(还有一些对文章里描述的吐槽)

3. 文中的靶子, 原文开头就说明是一个 API 需求, 何苦强调那么一点"通用性"的差异而将其作为靶子立在那儿? 就算要立, 也该先论述一下 e.g. "这个 API 需求, 只是小部分的需求, 现实中我们用框架还要做很多别的事情, 而那些是 FastAPI 不能做的"?

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

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

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

所以, 我没有觉得这篇文章可以达到"如果看到有人把 Flask 和 FastAPI 放到一起比较，请把这篇文章的链接丢过去"的程度, 这只是"既然看到了 FastAPI, 也来看看 APIFlask 这个新项目", 文中立的靶子文章反而实在得很. 当然作者推介一下心血无可厚非, 第三方这么推, 不会只是因为标题这么写吧?

19

sylvos

2021-05-13 01:34:40 +08:00 via iPhone

@yxt 顶

20

kikyous

2021-05-13 09:46:13 +08:00

@yxt 同意，对用户来说 FastAPI 和 Flask 就是同类的可对比的框架。Flask 应该看到自己的不足，积极应对，而不是用这种自我保护的心态，那对 flask 和 flask 用户来说不是什么好事。

21

frostming

2021-05-13 09:54:57 +08:00

2

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

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

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

22

frostming

2021-05-13 09:57:15 +08:00

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

23

greyli

OP

2021-05-13 10:23:03 +08:00

@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 晚点回复，去吃早饭了。

24

Latin

2021-05-13 11:21:38 +08:00

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

25

greyli

OP

2021-05-13 11:23:27 +08:00

@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/

26

greyli

OP

2021-05-13 11:36:43 +08:00

@yxt

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

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

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

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

27

abersheeran

2021-05-13 12:03:10 +08:00

3

@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 框架的可以去看看我提到的这几个项目。

28

abersheeran

2021-05-13 12:37:43 +08:00

1

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

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

29

frostming

2021-05-13 13:23:21 +08:00

1

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

30

mansurx

2021-05-13 15:05:19 +08:00

1

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

31

l4ever

2021-05-13 18:45:30 +08:00

1

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

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

32

yxt

2021-05-13 22:36:41 +08:00

@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

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

33

ragnaroks

2021-05-13 23:41:59 +08:00

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

34

abersheeran

2021-05-14 09:25:35 +08:00

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

35

abersheeran

2021-05-14 09:38:58 +08:00

1

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

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

36

yxt

2021-05-14 10:04:45 +08:00 via Android

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

37

WilliamYang

2021-05-14 10:46:18 +08:00

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

38

opentrade

2021-05-15 09:35:13 +08:00 via Android

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

39

RRRoger

2021-05-19 11:20:20 +08:00

看过大佬的书牛皮