Python 3.11 稳定版发布啦，速度提升不小

[owtotwo]

我对这个版本期待挺久的了，今天瞅了一眼官网发现 Python 3.11.0 刚好更新了！

GIL 似乎还在，速度平均提升了 25%，应该是效率提升幅度最大的一次版本更新了。

[lx0758]

可喜可贺

[LindsayZhou]

几天前就收到邮件通知了，昨天晚上还开了一个 Ytb 直播。
说实话，包括直播，我对 steering council 做法不太感冒，挺多人不喜欢混乱的打包方式，我是不喜欢淡化 maillist ，切到 discuss.python.org 。虽然也有邮件列表模式，乱七八糟的没法看。

[zhlxsh]

问题来了，你们会升级吗？
我们这边是一些小项目，都运行在 3.6.8

[infun]

@zhlxsh
很多项目运行在 3.7.x 升级会有已经不维护的内部包不兼容
又没人有动力去维护这些包

[moen]

这下 Windows on ARM 可以正式用 py 了

[owtotwo]

@zhlxsh 一直在 3.8.10 目前不敢乱动

[elementp]

CPython 应该不太可能移除 GIL 了

[llsquaer]

一般猥琐发育..不在乎那点性能..用 3.8

[shinession]

要等项目的依赖包有支持才能升级, 3.10 的时候 pandas 等了两三个月,其中有个依赖一直没升级

[wxf666]

好奇会不会有其他语言的人，跑来说：恭喜，从慢 200 倍提升到慢 150 倍了

回他一句，继续说：对不起，刺痛你的心，戳到你肺管子了

[IsaacYoung]

恭喜，从慢 200 倍提升到慢 150 倍了

[westoy]

pip install pyston_lite_autoload 解千愁

[greatx]

恭喜，从慢 200 倍提升到慢 150 倍了

[nba2k9]

恭喜，从慢 200 倍提升到慢 150 倍了

[janxin]

下一个版本按照计划会有多运行时，GIL 确实还在。这样不会像之前多进程提升性能时导致多余的性能开销

[jinsongzhao]

@wxf666 比 C/C++慢 10 倍, 没那么夸张的慢。开发速度依赖 IDE ，也没那么夸张的快。

[n37r09u3]

恭喜，2030 年向慢 100 倍进发

[fgwmlhdkkkw]

https://youtrack.jetbrains.com/issue/PY-53104

[dragondove]

不要玩 python 慢的梗了，python 很多对性能依赖高的包都是 C 写的，使用起来性能差别不会特别大。关于 GIL 有 nogil 项目，虽然不知道什么时候能并到主线： https://github.com/colesbury/nogil

[cco]

还运行在 3.5 的版本，一直没时间去升级。

[julyclyde]

pypy 跟上来了吗？

[zcreg]

恭喜，从慢 200 倍提升到慢 150 倍了

[paramagnetic]

需要高性能的部分，都是绞尽脑汁写成向量化的形式然后一个 ndarray 丢出去

[Kisesy]

python 自带一个 redemo.py 文件，打开就是一个测试正则的小工具，不知道为什么在新版里打不开了？

[superrichman]

现在固定一年一个版本，模块都适配不过来了 https://endoflife.date/python

[zictos]

还在用 3.7 ，升级要迁移老版本的一些模块，懒得去弄

[joApioVVx4M4X6Rf]

这么多年了，还是很喜欢用 python ，只希望它能多活几年哈哈哈哈哈

[tulongtou]

线上已经是 3.10.8 了，开发环境从 rc 就开始用 3.11 了，3.11 等出 2 、3 个小版本之后线上也可以升了。

[jjx]

比 python 2.7 快还是慢?

现在没有动力迁移, 怕迁了后更慢

[873792861]

一直用 3.7.9 ，也许再过半年，我买了新的笔记本电脑的时候会更新吧。也许，它会有 4090

[FrankHB]

@dragondove 依赖 C 什么时候是担保不特别慢的下限了？ Rubinius 比 CRuby 快的理由还是尽量用 Ruby 不用 C 实现呢……因为一旦用 C 写死了就无法继续用运行时优化了。
只有非常不依赖切换互操作上下文的任务（比如纯数值计算）才能现实通过本机实现提供像样的性能基线，然而越是这种情况往往越是没理由特别去用你这胶水，所以想要强调性能改进，这种东西是历来需要淡化的，你这哪壶不开提哪壶啊。

[dragondove]

@FrankHB 越是这种情况越是没理由？ python 的科学运算库可不少啊，底层都是 C ，性能相比其他语言也没太差，DL 方向用的最多的语言是哪个不用我说了吧

[FrankHB]

@dragondove 用户绝对数量再多，也不表示 python 在技术上就足够擅长。很多时候某个领域突然流行某种语言或者熄火了就是偶然的非技术因素，特别是长期有很多非专业人士凑数的、菜鸡互啄的众多交叉领域。严格点说，python 长期以来都是靠用户基数和惯性大来抢占市场，没有单一的应用领域存在护城河。而用户结构的松散导致 python 在外部都很难作为事实标准。
因此想要保持生态建设的、有点危机感的语言核心开发者，是不会很乐意强调这里性能多好的——说到底满足性能需求主要就不是 python 的功劳，只是勉强达到不拖后腿，能让人用得下去，才有机会一时流行；真要极端性能的，也不是没 x 嫌弃和抛弃 python 的。相对来说，他们更希望强调作为“胶水”语言“什么都能做”，然后最好用户忘了它经常可以被低成本地替代，才有余裕争取喘息的机会，继续改进。
要等他们还清在语言设计上的技术债来甩脱对性能的质疑……下辈子吧。

[wizardyhnr]

remove GIL 好像要把底层的一些 interpreter 实现改写完了才能实现。还要等 Faster CPython 慢慢改。
QA 也说了，主要是针对纯 Python 代码的速度改善，如果是 I/O 密集型或是底层已经用了 C 来提速的，可能看不到明显改善。

[chenqh]

各位的感觉提升了多少?

[hcocoa]

晕倒，昨天看还是 rc ，所以编译了 3.10 的，今天就发布了……

[u823tg]

@FrankHB #33 不知道你清楚的要表达什么。 性能对那个语言来说不重？生态对那个语言不重要？那个语言爆火都是非技术原因，但是爆火形成的生态基本上不可动摇。go 的容器，java 最初的 android ，python 的科学计算 dl ，js 的 web 。c++/c 的底层建筑。 这些都有替代品。问题是大家会放弃早形成的去用另一个语言去重构？ 这些语言那个没语言设计上的债。 那个不去提高性能了？

[wuwukai007]

个人项目一定要用 3.8+ 最好 3.10+ ，性能提升肉眼可见的

[victorc]

昨天安装了，又回退，在 windows 上，python3.11 安装 jupyter 需要依赖 rust 编译环境，太垃圾了

[FrankHB]

@u823tg 运行性能对不少语言本来就不重要，够用就行，现实几乎永远都是能节约开发成本更重要。
就 Python 的定位（“胶水”），性能向来就是被弱化的，但有的人被骗着骗着就觉得 Python 性能会成为瓶颈，强行要让 Python 做不擅长做的事以偷懒复用现有 Python 代码和廉价人力，结果就是迫使上游把大量资源投入到这种无底洞去了。现在回过头擦屁股，跟一开始就注意到性能瓶颈而从设计上约束，想实现相似的质量，需要花费的代价完全是两码事。像 Python 3.11 甚至爆改了 frame layout/table based exception handling 这种层面上的东西，结果体验的提升也才：“就这？”这样的费效比在工程上已经很严重了，类似的改进能持续多久属实没法乐观到哪去。当然，感知可能不明显，毕竟能有选择跳车的怕是大部分早就跑了。
至于所谓的生态不可动摇……你是不是对爆火有什么误解？能避免所谓的动摇的，只有被迫形成依赖而替换成本高企的杀手应用或者开发者（如 C++和 COBOL ），再者就是实现上有领先于其它绝大多数竞品的技术壁垒（如 Lua 和 Chez ），或者都有（如 JS ）。别的所谓生态，包括现存活跃用户的绝对数量，都没你想象中的那么不可动摇。而大多数语言都是比较尴尬的高不成低不就，(C)Python 也就是用的人特别多而尤其显著而已。（类似的例子……RoR 以前流行了好一阵子，没几年就不冷不热了。）
看你举例的备胎的例子，可以看出替换的可行性的差异感知得相当不明确。比如 C/C++可以整体被替换掉么？技术上可以，但是实际上没人能负担整体替换的成本，光考虑一点——几乎所有主要工业级的 C 、JS 和其它许多主流语言的实现都是依赖 C/C++，谁要动真格儿替换，至少还得把 FFI 之类的烂摊子收拾了，没想清楚替换哪些东西就赶鸭子上架，用不了多久就会出来各种旮旯不兼容停摆。反过来，替换“容器”“科学计算”之类的个别应用领域的东西，只要放弃少数相对来说，放弃少数设施或者人力（如果是造轮子狂魔甚至连放弃都不用），是可以短期内轻易做到避免现有基础设施的兼容性灾难的，所以仍能在合理的资源限制范围内被少数实体有效推进。这种不因为个别人意志而转移的困难程度，就是有和没有护城河的差别。而无论从哪个角度看，Python 都是属于近乎没有的。

[u823tg]

@FrankHB #40
第一点： 性能这个是微软 Faster CPython 团队的事，按你来说微软瞎搞啊提高啥性能，另外你让 cpython 团队其他方向也在弄啊。

第二 ： 那这样说放在每个语言里面都适用。 那个语言有绝对稳固的生态？ 我都说了爆火之后的生态基本没法动摇。Julia 科学计算比 python 好那么多大家咋不转。 有些东西都是降为打击，docker 容器化没出的话虚拟化大行其道，容器化火是因为虚拟化不努力被取代生态吗？ 同纬度下生态形成了有几个被替换的案例？
第三点： 你参考第二点， 那这样 java 所谓的护城河也没有，c/c++的护城河也没有，js 的 web 也没有， 按你说的都能替换都有替代方案只不过用的人没他们得多。都是现成的解决方案。

说到底感觉你为了反驳而反驳。 人家 python 提升性能让人家提升呗。 人家提升了你还让人家别宣传淡化。 按你这每个语言发布时都能调侃下。

[FrankHB]

@u823tg 微软瞎搞也多少是传统艺能了，特别是在资源投入上……不说新语言一向资源投入拉胯，既有产品中影响最普遍最该提高性能的 cl 生成代码质量常年都占不到对面吃烂 base ABI 亏的 tier 2 支持的 GCC 的便宜，不开源经常 ICE ，还有各种兼容烂活，比如 /clr bug 导致 STL 的 pr 合不进来的。
CPython 这帮人这么“上进”往这个方向上使劲，看起来像是被人忽悠瘸了。真要性能，还不如把不跟其它更像样实现兼容的东西用 spec 当 unspecified 强行钦定了（这才是只有 CPython 的人能做得到别的备胎实现做不到的），然后架构上全面转向 RPython 之类的更靠谱的方案。当然 native intreop 前期要维持兼容肯定会多吃亏，但是兼容性包袱本就是越拖越吃亏。而要是真要那么多对性能敏感的用户，被冷落是迟早的事，加上用你 CPython 一直就是兼容性而不是指望你性能真比别人好，你继续这一苟就两方面费力不讨好。

生态问题关键就一个分水岭：有没有实体能对全局变化兜底，给整个业界买单。C/C++是不能，JS 也是基本不能，因为现有设施的依赖太离谱了，干掉一个中间环节别的看似不相干的生态都得连锁崩一大片，没谁有这本事搞事干革命突然发明出备胎，给业界兜底。光是自己不用，都至少自绝于一个主要领域，比如不想碰 JS 基本就没法玩 Web 了，不想碰 C/C++么……回家玩 51 ？——不管是找现成备胎还是自己造都不现实。要干掉这类东西，只有一点点老实挖墙脚逐步蚕食份额，长期偷梁换柱才有可能，就这样完整性还捉急。（ C++替换一部分 C 用了几十年来着； WASM 还要带一坨小弟才能干掉 JS ，属实八字没一撇了。）
Python 显然没什么本事相提并论。可以说现在技术上就不存在离开 Python 就完全停摆的业务领域。尽管要故意不用导致现有解决方案失效，业界合计损失也可能是天文数字，但如果有足够长期额外利益，立即抛弃 Python 都仍然算是人力能及，还是有找备胎平替的可能性的——即使没有备胎，短时间新造也不至于动不动发现工程上不可能。反过来，要是编译器和操作系统内核之类几乎全沾上 C/C++实现的东西现在集体完蛋不给用，你拿 jio 给你搞出个能跑的 CPython 二进制？或者用其它语言新造备胎试试，要几年？还有，这样你 Python 当胶水去打算调用个啥（这不只是 CPython 的事，此时至少 Jython 和 IronPython 的运行时实现也已经完蛋了）？
注意就算没有非得立即淘汰 Python 的理由，看 Python 不爽去 Python 化的呼声多多少少是一直存在的，没在业界全面推广，就只是没有足够共识，而不像即使万众一心想搞掉 C/C++/JS （的历史包袱）都有心无力。
Java 啊，这方面还就是大号 Python 了，区别是没那么多非专业用户，惯性也更大。跟 Python 类似，看 Java 不爽的用户也多了去了，就算没本事干掉也能划清界限。现实中没 Java 能用得好好的、甚至表现得更好的设备实在太多了。
不过这方面本来就是跑题。提到这个，起因是有人提“用的最多”，而我指出绝对用户数任意多（甚至能忽略掉“最”）都不保证不被抛弃罢了。

而且你明显完全搞反了一点，我之前根本就没评论过 CPython 官方宣传如何。这次提升的就是非本机实现性能，有人还要说“对性能依赖高的包都是 C 写的”，这明显是跟官方宣传对着干吧？

[u823tg]

@FrankHB #42 你开心就好。

[LindsayZhou]

@FrankHB 基本上挺同意的，拿我自己的工作运维来说，运维有 Python 需求的原因就是容易学和适用范围广，能写 Web ， 能写爬虫，还能当 bash 用，要说替代的话，肯定都有其他替代。性能是锦上添花的东西，但不那么重要。

以前公司，我本地起个 asyncio 去爬运维系统 API 都能把它打崩，不过也没关系。这群不会开发的人，花上十天半个月能接手上就行。DL 那边做算法的人是不是这样？我不是很清楚。

（在这里在这里！我就是看 JS 和 Java 都不爽的人）

[wonderblank]

从这个帖子就可以看出来，整体而言，素质是多么的差。我也不是站在道德的制高点教你们做事儿，毕竟我也不给你们发工资。我最希望的是，简中技术社区得又个社区的样子，讨论技术，而不是这么多的无意义灌水。Python 社区很大，发布新版本了，可以看看有没有新的优化，比如 asyncio 有没有加入新的后端(io_uring 等)，GIL 的问题有没有缓解，以及那些库不兼容。

> 恭喜，从慢 200 倍提升到慢 150 倍了

> https://news.ycombinator.com/item?id=32002057

[owtotwo]

Python 3.11 没赶上 Ubuntu 22.04 LTS 有点可惜

不知道即将到来的 Fedora 37 是否会用上 Python 3.11.0 (测试版似乎带的是 Python 3.11 rc 版)

[julyclyde]

@LindsayZhou 加个 gevent 不就顶住了？也不需要额外写什么啊，monkey patch 一下就行了