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/

[ice2016]

看看新版本··

[janxin]

赞👍

[misaka19000]

哇，奈斯

[xiaomingVTEX]

新路由挺好

[abersheeran]

看到 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 。

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

[wellsc]

当年入行的时候全靠 0.1x

[onbeam]

刚看到 大佬出的 flask 书

[CallMeReznov]

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

用官方源更新过去了

[chenqh]

我还在用 tornado,套

[zhengdai1990]

fastapi 据说比它好？

[maobukui]

@zhengdai1990

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

[greyli]

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

[olddog5172]

大佬的网站怎么打不开了

[johnsona]

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

[Kilerd]

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

[abersheeran]

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

[greyli]

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

[yxt]

作为一个 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 这个新项目", 文中立的靶子文章反而实在得很. 当然作者推介一下心血无可厚非, 第三方这么推, 不会只是因为标题这么写吧?

[sylvos]

@yxt 顶

[kikyous]

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