@ericls 行。等你搞完，我去给你 star

@Jirajine https://aber.sh/articles/How-to-writing-functional-Python/ 一点我写函数式 Python 的心得。我不觉得有不友好，可能是我和你的使用习惯不一样，你可以看一看我的以作参考。

@ericls 你先自己试试再说吧。Talk is cheap

@maocat 这个是小问题。合并两个字典列表，一行代码就够了。

@23333333333 还行，Django 官方不提供接口，只能自己找方法了。说实话，这玩意让 Django 自己来做更好，奈何那群人不知道天天在想什么。你看这么多年都不支持 PUT 的请求体解析、TestClient 不支持 PUT 提交多段表单格式的数据。反正我现在不用 Django 。如果不是朋友找我帮忙，这个序列化方法我可能会让它一直停留在脑海里。

@ericls 目前来说，这已经是最佳的解决方法了——不显式的自己写预查询，这个序列化功能就不会给序列化外键数据。至于你说的 check，你可以试试给 Django 提 PR，反正我不抱有任何乐观看法。

@ericls 我说的 N+1 是 Django ORM 导致的 N+1 。业务上的 N+1 问题是另一回事。

我觉得这个 PEP 还真不应该撤回。它解决了两个痛点，第一是 typing 模块拖慢 Python 运行速度，一份满满都是 type hint 的 Python 代码远比啥也不加的要慢。第二个是取消了类型注释的运行时影响，在我编写代码的时候，我不喜欢写 Any，所以经常遇见一个类方法 /属性返回另一个类，而另一个类里也有方法 /属性返回这个类，而这两个类又是不同功能，放在不同模块的，从而导致循环引入问题。最重要的是，它终于实现了 typing 一开始的承诺——无运行时影响。运行时影响本身就是一个实现上的 BUG 。

pydantic 作者反对，大概是因为代码写好了不愿意动（他最近也挺忙的），我十分理解他的心情。但 fastapi/starlette 就算了吧，代码里面多少 Any 看过的人都有数，这个 pep 对它来说就是可有可无。

---

楼上说到性能，社区现在也有使用 type hint 作为元信息进行编译加速的，虽然还是个半成品，但也在发展了。而且据说 Python Core Developers 也在筹措 CPython JIT 的事。

我倒觉得与其炮轰这个，不如让那些家伙别再加语法糖了，把精力放在 JIT 上不好吗。

@wakzz 无非是没遇到触动他心境的事罢了。

@wakzz 哪有这种心境高妙如太上的人，都是俗人，心态不平很正常。

跳表。

翻到自己九年前的诗词，应该别有一番风味吧。不知心境变否？

@selypan 好，期待中。

看起来确实挺好，但是中间安全怎么保证呢？这种东西感觉还是卖源码自己部署会让用户放心一点。

@zhaofy 他新开了两个小号装成三个人。你就别在这配合了，看他演就行了。