[想法] 给 Django 增加 Pydantic 支持

[abersheeran]

先说我的观点，FastAPI 是拼接怪，在我心里跟 flask 这个玩具的地位差不多。可以用，但是没必要。

Django 在我心里仍然是目前最好的 Python web 框架。但是 Django rest framework 我也觉得是个狗屎，我两年前试图用不成熟的想法挑战 drf 的地位，最后发现自己也只能是再创造一个 drf 。

pydantic 的流行是一个契机，我自己的 web 框架 index.py 设计本身与 pydantic 就是弱耦合的，完全可以把这部分经验挪到 Django 上。成品的使用方法可能会类似于 index.py/openapi

就是不知道大家的看法如何？是否值得去做？

如果支持的人多，我会把接下来几周的周末时间拿来完成这个项目。

看起来支持的人不多，那就算了。此项目搁置，我还是接着用 Django 手写 API 接口吧。

[wuwukai007]

确实，拼接怪有画面了

[cz5424]

说 Flask 是玩具就过分了

[Aeoluze]

妙啊，有点期待

[lithbitren]

你问我支不支持，那我肯定是支持的

[guyskk0x0]

不知楼主有没有看过 https://github.com/guyskk/validr，我把它和 drf 一起用还挺爽的。pydantic 给我感觉的是太弱，局限于 type hits 了，虽然我的项目也没几个 star 。

感觉你写一个能兼容现有生态且性能更好的路由，更容易持续做下去，虽然 Tom 不喜欢但你 show the code 他说不定就改变看法了。

[guyskk0x0]

另外我记得 werkzeug 里是把所有路由拼成一个大正则，匹配效率很高的。

[Jat001]

flask 是玩具还行，原来过去几年我一直在玩玩具

[Trim21]

不知道能不能把 fastapi 这部分挪出来，单独做成一个库，这样底层到底是什么框架就无所谓了

[abersheeran]

@Trim21 不可能。路由是每个 web 框架的根基，除了 fastapi 这种拼接怪以外，基本都是自己写的。做不到适配。而且 fastapi 在这部分根本没做什么，全都是 pydantic 的功劳。

[Trim21]

@abersheeran #9 我的意思 handler 的 type hint 和依赖注入这部分，底层的路由还用各个框架自己的东西

[abersheeran]

@guyskk0x0 这个库看起来不错，不过 pydantic 的主要功能不在校验上，而是可以针对大量不同格式的数据模型生成 OpenAPI 文档。如果只是校验功能，我写 Django 的时候会选择直接使用它原生的 Form 。

[Trim21]

https://gist.github.com/Trim21/ff52a01006b73146d1f744ed06400e1b

[abersheeran]

@guyskk0x0 所以为什么我还得委屈求全，求着别人用我的代码？我做开源就是跪不下去。Tom 的 starlette 就像是艺术品，我尊重他的代码且贡献了一些优化，但我同样看得起我自己的成果。他不愿意，那就算了。并且这个并不是他一个人不愿意，encode 的其他成员也不愿意。

[abersheeran]

@Trim21 那就没办法生成文档，功能等于少一大半。

[Trim21]

@abersheeran #14 文档可以赋值给 handler 的一个属性，然后再针对每一个框架提供一个方法来把所有的路由和 handler 来处理一下，正好可以针对不同的框架要用到不同的路由语法

[abersheeran]

@Trim21 想法不错。不过 Python 的 web 框架，除了 Django 我就只愿意用我自己的 index.py 。

[Trim21]

@abersheeran #16 正好这样支持两个框架，别人还能 pr 别的框架的支持

[so1n]

我之前每个框架都要写一个校验装饰器,所以也产生了写一个所有框架都可以用的类似于 fastapi 参数校验和转换的库, 前段时间开始动手了,想着可以套在大部分的 python web 框架, 前期通过 starlette 和 flask 框架来验证功能,不过还不可以用于生产环境,目前只做了接口的校验和检测功能
https://github.com/so1n/pait

[abersheeran]

@so1n 这个不错，不过使用体验可以再优化优化，有些冗余。

@so1n @Trim21 两位，我们创建一个组织一起来做这个吧。支持多种框架的参数校验和自动 OpenAPI 文档生成，感觉比较有意思。

[Trim21]

@abersheeran #19 我感觉行（

[nonduality]

支持！

[guyskk0x0]

@abersheeran #11 validr 也很容易用来生成 API 文档，Schema 对象包含了全部元信息。
@abersheeran #13 也不是说求着别人用，这是框架生态问题，另起灶炉没有问题，只是受众会少很多。如果你做的是 Library 那没有问题，不和框架绑定可以灵活替换。如果你做的是一个框架，使用方就会顾虑了，框架只能用一个而且用上了就很难换，还要考虑大量周边工具是否完善和丰富。

[so1n]

@abersheeran 行啊

[workwonder]

能了解下“拼接怪”是指什么吗？

[AX5N]

@workwonder 主语是谁

[johnsona]

就冲你说 flask 是个玩具，我们就是统一战线

[johnsona]

很多人提到自动生成文档，我不清楚你们生产环境 swagger 用的怎么样，我感觉还是手动比较好

[abersheeran]

@guyskk0x0 pydantic 可以直接用。validr 得自己读元信息生成。这一点我站 pydantic 。
而且我个人更喜欢类型去标识，我甚至想更加极端一点，把所有元信息全部放在类型里，这样甚至可以让 mypy 在检查时就能预读出更多错误。
最后一点，Python 即将加入模式匹配，类型才是未来。

@workwonder fastapi 只是把 starlette 和 pydantic 拼接起来。如果我把 Django 和 pydantic 拼起来说自己是一个新 web 框架，是不是太猥琐了？

[abersheeran]

@Trim21 @so1n 那就留个邮箱？我发 QQ 号给你们。

[abersheeran]

@guyskk0x0 我听过最好笑的事就是微框架有生态。flask/starlette/fastapi/responder 这些微框架除了路由和基本的请求响应以外，几乎没有其他功能。所谓的“生态”基本都是弱耦合的。我可以这么说，fastapi 的生态一大半来自于 starlette 。而我的 index.py 与 starlette 一样是实现了标准 ASGI2.1 接口，starlette/fastapi 能用的生态，我也可以用。

各种微框架最大优势不是生态，而是名头。你一看 fastapi 上万 star，感觉还行，可以用。再看 index.py 一皱眉，花精力研究一个不流行框架不合适，于是你不用。这很正常。我也不会轻易尝试使用人数太少的东西。除非我参与了开发，或者我很懂它。

[fushall]

fastapi 不香吗

[so1n]

@abersheeran cWF6NjgwMzYwOUAxNjMuY29t

[burryLove]

flask 是玩具????

[sylvos]

qqq

[sylvos]

有一个 spectree 库

[scyangjian]

66666

[frostming]

短短一段话，好多暴论

FastAPI 是个拼接怪，我不说话
Flask 是个玩具，我略有微词
DRF 是个狗屎，这？

[abersheeran]

@frostming 哈哈哈，我不喜欢 DRF 那种侵入式的写法。写出来的味儿都不是 Django 了，就感觉是新整一个 API 框架出来。