@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 他新开了两个小号装成三个人。你就别在这配合了，看他演就行了。

@vitovan 哈哈哈，笑出六块腹肌。

虽然我一直白嫖，但是支持一波楼主。楼上用盗版的也收敛点，没人像楼主一样付费，哪儿有白嫖的机会？用盗版还让人家向你们学习也是够了。“我都关着灯！”。

显然前三者都是盗版，微信读书我不用，不清楚。

同人小说那个，好像不算。

MIT 那个，我觉得根目录下放置 MIT 而文件中没有显式申明，应当默认是 MIT 的。

最后一个，显然不行。但实际执行不下去。996 都成了“特殊工时制度”被深圳合法化了。

不会。
@LeeReamond