Python 3.12 有什么新变化
以下为主要改动：

f-string 支持更复杂的解析，或许有用但没想到能有多大用；
Per-Interpreter GIL ，但仅限 C-API 。所以裸写 Python 的 GIL 还在，目前预计 3.13 才会有 可选 的 No-GIL Python 解释器；
新的类型标注支持，对 type hints 的泛型部分有补充，但离完善还有些进步空间；
distutils 包弃用，在弃用列表中这个的影响可能相对较大；
各模块的优化改进，包括 os 及 asyncio 等；

感觉并没有什么动力升级到此版本，因为看了半天发现：
模块中新增的 itertools.batched(iterable, n) 函数可能是对我而言“最大”的改动 XD

Python 不如激进点，发布 Python 4 ，采用 No-GIL 和 JITGolang 也不如激进点，发布 Go 2.0 ，采用 cargo-like 管理C++更需要激进点，发布 New Carbon ，直接干翻 C 和 Java我在想桃子.jpg

还在用 3.9, 不出毛病我为什么要升级

f-string 可以单引号套单引号了吧，这个比较有用

希望 pytorch 升级下 python 版本, 不然大家都只能绑死在 3.10.6 哈哈

type hints 新语法很漂亮

以前也是追新的稳定版，直到认识了 pytorch ，哈哈哈

想要体验 Python 代码创建子解释器，可以尝试这个库： github.com/aisk/backports.interpreters

pytorch 2.0.1 已经有 py3.11 了

除非用纯 py 写代码，不然三方包兼容测试累死人

现在写个 python 要写得舒服，到处都要加 type hints ，3.12 里 type 成为软关键词之后甚至可以 type Point[T] = tuple[T, T] type HashableSequence[T: Hashable] = Sequence[T]建议直接发布 TypePython 改成强类型语言 [:doge]

3.8 以后就跟不上了， 算了

3.11 以后感觉... 除了性能, 其他已经挺好了, 别折腾了不过 dict[str, str] 这个是真挺好的, 可惜没法通过 future 向后兼容.子解释器啥的, 给我个装饰器把某个纯函数避开 GIL 也行, 做那么复杂, 越复杂越不健壮啊. 不要自行车

docs.python.org/3.12/howto/perf_profiling.html我觉得这个很有帮助。

不做大项目,真不爱写 type hints,看起来乱七八糟,丝毫没有简约美

要不是 python 库多，真不想用，坑太多了。

用的不多，一直不敢说，没想到也有很多人和我一样觉得这玩意儿不好写==不是 chatgpt 帮忙我得哭死

wasm

gvim 尚未适配 3.12 ，被迫回退

是的 以前都单层嵌套的单引号套双引号 想再嵌套都会考虑拆开写3.12 的 f-string 可能更依赖语法高亮了

现在能类型标注的都会标上 但写 Python 又希望简短精炼 写起来总有种左灯右行的冲突(type hints 冗长显眼 typeCheckingMode 开 strict 时外部库对类型标注支持又不好一片标红 看着血压拉满)

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 不兼容