看标题还以为是硬盘分区多了…

我是总声望前 20 的用户。当年社区比较小众时，问题质量还是比较高的。后来社区推广开了，大量小白和卖课的涌入，问题质量开始下滑。加上后来问答版块被边缘化，慢慢也就觉得没意思了。感觉和知乎是一样的毛病。

recv 不保证一次接收完，你要用一个循环读

我说一个观点，就是在 CPython 漫长的发展过程中 Extension 的接口会发生抽象泄漏，从而制约其底层实现的改变。具体可以看 Hyrum's Law https://www.hyrumslaw.com/

展开来说，一个有很多用户使用的接口，无论其抽象做的多好，用户的使用最终多少会透过这层接口而去依赖背后的具体实现。CPython Extension API 虽然没有暴露太多和 GIL 相关的 API ，但你很难说不存在某些扩展，其正确性依赖于「解释器里有个全局锁」这一事实。就算细粒度锁或去除 GIL 的性能和安全问题解决了，CPython 作为正统及使用最广泛的版本也不会贸然采用。这其中会有很长的验证过程。

应该是是 response 的 content type 在影响，感觉没有比尝试发一个请求更靠谱的办法

大数据感觉比前端好吧

@eluotao 看过事故锦集视频的应该知道王者是什么，我觉得楼主只是顺口说出来了。也不用这样说楼主吧

ubuntu 用了六七年了，感觉很好

... def valid_before_logout(func):
... ... def execute(self, *args, **kwargs):

数据规模多大？

还有另一个问题是你要考虑 lambda 所在的闭包，看一个例子

def f():
... a = 1
... return lambda: a + 1
a = 1
f().__code__.co_code == (lambda: a + 1).__code__.co_code # False

这两个 lambda 虽然代码相同但是他们字节码不一样。原因是 f() 中的 a 是个 local 变量，读取时会使用 LOAD_DEREF ；而后一个是 global 变量，读取时会使用 LOAD_GLOBAL 。总而言之 corner cases 有很多很多

@O5oz6z3 #16 co_code 不可靠，一个简单的反例

(lambda: print(1)).__code__.co_code == (lambda: sum(1)).__code__.co_code # True

这是因为变量名一类的不存在于字节码中，而是在 __code__.co_names 里

@abersheeran 我当时的解决方法是强制用户给同一行的 lambda 加不同的前缀，当然这个就比较丑了。同期待更好的方法

@penguinWWY co_linetable 应该只存了行号，co_columntable 能拿到列号，但这是 3.10 新加的，兼容性不太好

@hsfzxjy #3 这个在 3.5-3.10 应该都可以，2.7.没测过

我之前实现一个拿 lambda 的 AST 的功能，但这个有个限制就是需要保证前置的 token 是固定的，具体可参考 https://github.com/hsfzxjy/lambdex/blob/master/lambdex/utils/ast.py#L97

比如要求用户写成 def_(lambda: ...) ，然后将这个 lambda 对象以及字符串 'def_' 传入这个函数，就可以拿到 AST

可能对你有帮助

比较生草，已 star

好奇这个突起的摄像头能平放在桌面吗？

找个好看的字体写个「基」