Python 3.12 稳定版发布啦，哪个改动最有吸引力？

[owtotwo]

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

[imes]

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

[aitianci]

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

[Muniesa]

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

[Mohanson]

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

[hsfzxjy]

type hints 新语法很漂亮

[youthfire]

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

[aisk]

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

[Death]

@Mohanson
pytorch 2.0.1 已经有 py3.11 了

[NoOneNoBody]

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

[Kirscheis]

现在写个 python 要写得舒服，到处都要加 type hints ，3.12 里 type 成为软关键词之后甚至可以

type Point[T] = tuple[T, T]

type HashableSequence[T: Hashable] = Sequence[T]

建议直接发布 TypePython 改成强类型语言 [:doge]

[iorilu]

3.8 以后就跟不上了， 算了

[ClericPy]

3.11 以后感觉... 除了性能, 其他已经挺好了, 别折腾了

不过 dict[str, str] 这个是真挺好的, 可惜没法通过 future 向后兼容.

子解释器啥的, 给我个装饰器把某个纯函数避开 GIL 也行, 做那么复杂, 越复杂越不健壮啊. 不要自行车

[kkocdko]

https://docs.python.org/3.12/howto/perf_profiling.html

我觉得这个很有帮助。

[customsshen]

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

[sunzhuo]

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

[winterbells]

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

[huangsen365]

wasm

[kawaiidora]

gvim 尚未适配 3.12 ，被迫回退

[owtotwo]

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

[owtotwo]

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

[aploium]

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

[uni]

类型啊
我之前就是因为类型，甚至无法从 3.11 退回 3.10

[kneo]

“Per-Interpreter GIL ，但仅限 C-API 。所以裸写 Python 的 GIL 还在……”
不管 Python 还是 C ，GIL 都在。

“目前预计 3.13 才会有 可选 的 No-GIL Python 解释器”
应该没戏。

[lanlanye]

新的泛型写法可能会成为我升级的动力

[sdsaaeee]

可能一些库不兼容，对 12 无感，现在 11

[owtotwo]

@kneo 对于前者，是的，GIL 都在。

原话的完全句子是 _“目前的 Per-Interpreter GIL 子解释器仅供使用 C-API 创建，而暂时并不支持仅使用 Python 代码创建。所以编写纯 Python 代码时 GIL 对多线程并行的性能影响尚在。”_ （请原谅我的措辞不当）

Faster CPython 的 Plan 中有提到使用 Python 代码创建此类子解释器 [Enabling subinterpreters from Python]( https://github.com/faster-cpython/ideas/blob/0905dcc8ba76ff1f49b173437f4bc9359aa5ca19/3.13/README.md#enabling-subinterpreters-from-python) 。

对于后者，是今年 1 月份创建的 PEP 中 [PEP 703 – Making the Global Interpreter Lock Optional in CPython]( https://peps.python.org/pep-0703/) 提到的，但是否真能在明年 3.13-rc 版赶出来，感觉持悲观态度，要实现 `--disable-gil` ，看起来难度并不低。

[owtotwo]

@uni @lanlanye @sdsaaeee 我也是因为新的类型标注功能，在今年将 3.8 升到 3.11 了。

目前截至 2023 年 10 月份，对 3.11 而言，库的兼容程度比预想中的要好。

@Mohanson @youthfir 另外 PyTorch 2.1.0 Stable 版本昨天发布了，已经支持了 Python 3.11 ，或许可以考虑升级了~

[PyTorch 2.1: automatic dynamic shape compilation, distributed checkpointing]( https://github.com/pytorch/pytorch/releases/tag/v2.1.0)

[Support Python 3.11 #86566]( https://github.com/pytorch/pytorch/issues/86566)
e

[neoblackcap]

@Kirscheis Python 已经是强类型的语言，看看它报错就知道了，它可是能知道所有变量的类型的。而且不管是什么错它都有处理，而不是直接 core dump

[crackidz]

其实 3.12 提供的 Per-Interpreter GIL 其实已经可以释放很多性能了，起手一个 C-Loader 后面跟 Python 代码就行了，以后不用考虑多进程的问题

TypeHits 用起来很爽，多加点多加点

[akaHenry]

Python 4.0 不是 Mojo 吗？ 狗头🐶。。。

Python 3.8 之后的新版本更新， 都是比较无聊的特性。

作为脚本语言，干啥都是二把刀，认清客观现实，怎么糊的快，怎么糊的爽，怎么来。

脱裤子放屁的事，少干。

整一堆没用的优化，不如换个语言(Rust/Zig/Go/Mojo) 随便选。

写脚本，就要有写脚本的觉悟。