diskcache

Per-Interpreter GIL 真是丑陋，他的作者在 nogil 的 PEP 讨论上说他不支持 nogil ，因为他已经花了 8 年在 Per-Interpreter GIL 上，他认为这已经足够解决 python 的多核问题了。 幸好群众不认同，我无法想象另一条世界线上未来被迫用这种学院派玩意写多核。
语言层面没什么对我有用的改进，软 type 语法为了兼容 pypy/pyston 也没法用
相比 Per-Interpreter GIL ，Immortal Objects 这种才是 end-user 在生产中有痛点后提出的有效改进。它对 nogil 巨大的助攻，如果没有它，nogil 的性能会下降一截。而且对实际的多核 python 程序(通常会假设有 fork 机制，很多内存可以 share)能减少很多(对我来说可能有十几个 G)无效内存 Copy On Write 。

对了建议路过的观众在用 3.11 以下的，去尝试一下 pyston-lite ，通过 frame-eval 加入简单的 jit ，来实现免费的性能午餐，但是和 torch 2.0 不兼容

你要是非得在 windows 下用 python 的话, 用 WSL+Anaconda 吧

可以用 sqlalchemy 自带的连接池, 如
engine=sqlalchemy.create_engine(DB_URL)
result_proxy=engine.execute('some sql')
rows=result_proxy.fetchall()

不用专门去考虑连接池和释放的问题, 里面内置了

跳转到 cdnjs.com 的根了, 以前是跳到对应资源

确定不是选了 按流量付费?

@Cu635 #12 而且并不是技术到了就能用了, 超高密度电池在 paper 里早就有了
即使民用, 首先也是医疗之类不计成本的地方
等到技术成熟, 成本压下来了才可能跑到手机上

降低功耗和减少元件体积对续航的提升比电池能量密度的提升快(经验, 有待考证)

emmm 说不定等到 USB4.0 出来的时候就能两天充一次电了(无责任瞎猜)

大的突破首先会用在军事

友情帮顶

虽然在知道加密方式的前提下非常容易攻破, 不过用来欺骗别人的 base64 解码器倒是可以的 (可是那为什么不简单地 AES 一下)

@oh #10 192.168.0.0/16 下面的机器都是在同一个交换机下的, ip 可以随意分配
上级网络 10.0.0.0/8 下面的 ip 很可能是按照 vlan 做了地址段限制的, 并不能像 192 那样自动解决冲突
当然如果你一定要说有办法检测冲突并且自适应, 那我也没话说, 导致很大的编程复杂度和不确定性

因为家庭路由器所需要的 ip 数很小, 192.168.x.y/24 就已经足够足够用 (252 个 IP)
而 10.0.0.0/8 有 1600 多万个 ip
并且很多公司内网、学校内网、电信区域 NAT 内网都是用 10.0.0.0/8 段的, 要是默认设置成 10.0.0.0/8, 就会冲突, 或者需要配置非常复杂的路由表


以上为个人推断

火前留名，以后再来截图给朋友炫耀

没碰到这个问题。

@Kilerd #3 递归就没办法了，毕竟不是常见的需求