以下为主要改动：
感觉并没有什么动力升级到此版本，因为看了半天发现：
模块中新增的 itertools.batched(iterable, n) 函数可能是对我而言“最大”的改动 XD
 |
1
cmos Oct 3, 2023  4
Python 不如激进点，发布 Python 4 ，采用 No-GIL 和 JIT
Golang 也不如激进点，发布 Go 2.0 ，采用 cargo-like 管理 C++更需要激进点，发布 New Carbon ，直接干翻 C 和 Java 我在想桃子.jpg |
 |
2
aitianci Oct 3, 2023 1
还在用 3.9, 不出毛病我为什么要升级
|
 |
3
Muniesa Oct 3, 2023 via Android 1
f-string 可以单引号套单引号了吧，这个比较有用
|
 |
4
Mohanson Oct 3, 2023
希望 pytorch 升级下 python 版本, 不然大家都只能绑死在 3.10.6 哈哈
|
 |
5
hsfzxjy Oct 3, 2023 via Android
type hints 新语法很漂亮
|
 |
6
youthfire Oct 3, 2023 via iPhone
以前也是追新的稳定版，直到认识了 pytorch ，哈哈哈
|
 |
7
aisk Oct 3, 2023
想要体验 Python 代码创建子解释器，可以尝试这个库： https://github.com/aisk/backports.interpreters
|
 |
9
NoOneNoBody Oct 3, 2023
除非用纯 py 写代码，不然
三方包兼容测试累死人 |
 |
10
Kirscheis Oct 3, 2023
现在写个 python 要写得舒服，到处都要加 type hints ，3.12 里 type 成为软关键词之后甚至可以
type Point[T] = tuple[T, T] type HashableSequence[T: Hashable] = Sequence[T] 建议直接发布 TypePython 改成强类型语言 [:doge] |
 |
11
iorilu Oct 3, 2023
3.8 以后就跟不上了， 算了
|
 |
12
ClericPy Oct 3, 2023 1
3.11 以后感觉... 除了性能, 其他已经挺好了, 别折腾了
不过 dict[str, str] 这个是真挺好的, 可惜没法通过 future 向后兼容. 子解释器啥的, 给我个装饰器把某个纯函数避开 GIL 也行, 做那么复杂, 越复杂越不健壮啊. 不要自行车 |
 |
13
kkocdko Oct 3, 2023
|
 |
14
customsshen Oct 3, 2023 1
不做大项目,真不爱写 type hints,看起来乱七八糟,丝毫没有简约美
|
 |
15
sunzhuo Oct 3, 2023
要不是 python 库多，真不想用，坑太多了。
|
 |
16
300 Oct 3, 2023
用的不多，一直不敢说，没想到也有很多人和我一样觉得这玩意儿不好写==
不是 chatgpt 帮忙我得哭死 |
 |
17
huangsen365 Oct 3, 2023 via Android
wasm
|
 |
18
kawaiidora Oct 4, 2023
gvim 尚未适配 3.12 ，被迫回退
|
 |
20
owtotwo OP @Kirscheis 现在能类型标注的都会标上 但写 Python 又希望简短精炼 写起来总有种左灯右行的冲突
(type hints 冗长显眼 typeCheckingMode 开 strict 时外部库对类型标注支持又不好一片标红 看着血压拉满) |
 |
21
aploium Oct 4, 2023 1
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 不兼容 |
 |
22
uni Oct 4, 2023
类型啊
我之前就是因为类型，甚至无法从 3.11 退回 3.10 |
 |
23
kneo Oct 4, 2023 via Android
“Per-Interpreter GIL ，但仅限 C-API 。所以裸写 Python 的 GIL 还在……”
不管 Python 还是 C ，GIL 都在。 “目前预计 3.13 才会有 可选 的 No-GIL Python 解释器” 应该没戏。 |
 |
24
lanlanye Oct 5, 2023
新的泛型写法可能会成为我升级的动力
|
 |
25
sdsaaeee Oct 5, 2023
可能一些库不兼容，对 12 无感，现在 11
|
|
26
owtotwo OP @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` ，看起来难度并不低。 |
|
27
owtotwo OP @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 |
 |
28
neoblackcap Oct 5, 2023
@Kirscheis Python 已经是强类型的语言，看看它报错就知道了，它可是能知道所有变量的类型的。而且不管是什么错它都有处理，而不是直接 core dump
|
 |
29
crackidz Oct 5, 2023
其实 3.12 提供的 Per-Interpreter GIL 其实已经可以释放很多性能了，起手一个 C-Loader 后面跟 Python 代码就行了，以后不用考虑多进程的问题
TypeHits 用起来很爽，多加点多加点 |
 |
30
akaHenry Oct 12, 2023
Python 4.0 不是 Mojo 吗？ 狗头🐶。。。
Python 3.8 之后的新版本更新， 都是比较无聊的特性。 作为脚本语言，干啥都是二把刀，认清客观现实，怎么糊的快，怎么糊的爽，怎么来。 脱裤子放屁的事，少干。 整一堆没用的优化，不如换个语言(Rust/Zig/Go/Mojo) 随便选。 写脚本，就要有写脚本的觉悟。 |
Select Language