Python 团队官宣下线 GIL

本文介绍了几个 Python 相关的更新和新功能。首先,Python 摆脱了 GIL(全局解释器锁)。接着,我们看到了 LPython 的发布,这是一个新的 Python 编译器,同时还有 Pydantic 2 版本的发布,该版本更加可用。接下来,我们讨论了 PEP 387,该提案定义了软弃用,并且 getopt 和 optparse 被软弃用。紧接着,Cython 3.0 版本发布,对纯 Python 支持更加出色。另外,PEP 722 也在文中提及,该提案定义了单文件脚本的依赖规范。最后,我们还讨论了在 VSCode 上 Python 支持的改进,以及终端中运行的画图程序。这些更新和新功能为 Python 开发者带来了更多的选择和便利。

永远摆脱 GIL 的 Python

上个月全局解释器锁(Global Interpreter Lock,GIL)再次成为关注的焦点。这个月,甚至连 Facebook 的母公司 Meta 都参与其中

如果 PEP 703 被接受,Meta 将会承诺支持,在 CPython 中提供三名工程师年的 nogil(无 GIL)支持。(注:"engineer years" 指的是一名工程师在一年内的工作时间。)

很高兴看到越来越多的大公司为 Python 的成功做出贡献。与 2010 年代相比,这是一个巨大的变化

关于 PEP 703 的讨论在核心开发人员中达到高潮,最后做出了一个正式声明,即将接受重新点燃激情的提案,但需要解决一些细节问题。

这意味着在未来几年内,Python 将摆脱全局解释器锁。

以下是计划:

  • 短期内,将同时发布一个不受支持的实验性 Python 版本,该版本不包含 GIL,目标版本是 3.13/3.14。
  • 中期内,将标记无 GIL 版本为正式支持版本,但仍然是 Python 带有 GIL 版本的替代品。将宣布一个目标日期,使其成为默认版本。这将只会在社区表现出足够支持的情况下发生,并将需要几年的时间。
  • 长期内,无 GIL 版本将成为默认版本。在此之前,核心开发人员可以撤销该决定并中止无 GIL 项目,如果该项目被证明回报率不佳。

请注意,如果程序导入了一个单一的使用 GIL 的 C 扩展,在无 GIL 版本的构建中,它将自动切换回 GIL 版本。因此,这不是一个 2=>3 的情况,不会导致不兼容的代码破坏。

两种不同的构建版本的主要原因是管理未知的未知情况。事实上,没有人预料到无 GIL 会出现问题,但对于如此大的项目,你永远无法确定。ABI 兼容性很复杂,新扩展需要针对其进行显式编译,才能使其正常工作,所以需要社区的支持。

而且,无 GIL 兼容的扩展将在旧解释器上工作,因此不会出现类似 Python 3 代码不适用于 Python 2 的情况。

实际上,Python 代码本身不应受到影响,并且在其中一个版本上或另一个版本上都可以无缝工作,尽管在带有 GIL 的版本中线程被限制在单个核心上。

LPython:一个新的 Python 编译器

这是我没有预料到的消息。在《CPython、Pypy、MicroPython、Jython 是什么鬼?》(What's the deal with CPython, Pypy, MicroPython, Jython...?)这篇文章中,我们讨论了 Python 编译器,我认为我在列举所有重要内容方面做得相当不错。然而,LPython 团队决定在此基础上继续扩展。

LPython 是一个新的 BSD 3 编译器,它可以将 Python 代码翻译为 LLVM、C、C++或 WASM。它的目标不是编译整个程序,虽然它也能做到,但更像是 numba 和 cython 一样,让你加速数值瓶颈。基准测试非常有希望,并且在 AOT(Ahead-of-Time)和 JIT(Just-in-Time)之间切换的能力非常方便,尽管你仍然需要在机器上安装整个编译链。LPython 喜欢原始的 Python 代码,因此如果在片段中调用 Python 函数,你必须使用装饰器显式标记它为 Python 函数。因此,大多数人可能会将其用于非常具体的代码片段。

Pydantic 2 变得更加可用了

我一直在宣传 Pydantic 的第二个版本的到来,因为我和很多人都经常使用它进行数据验证和架构定义,而新版本更加快速。

没错,它上个月发布了稳定版,但如果你读过《缓解你的 Python 打包痛苦》(Relieving your Python packaging pain),你会知道我不鼓励人们使用最新版本的东西,除非用于测试或者娱乐。

事实上,即使是稳定的主要版本,也仍然需要完善,并且社区支持较少。

但现在发生了两件事情:

现在,我将尝试在一个个人项目中使用它,如果有效,几个月后再将其应用于专业项目中。

PEP 387 定义了“软弃用”,getopt 和 optparse 被软弃用

如果你还没有阅读 Victor Stinner 的博客,我鼓励你去读一下。这是一篇技术性和原汁原味的博文,毫不掺杂废话,让你能够深入了解核心开发人员的贡献生活。最新一篇文章提到了我在上个月忽略的一件事:软弃用已被添加到 PEP 387——向后兼容性策略

这份于 2009 年创建的文档规定了 Python 项目如何处理弃用问题,现在它将包含以下内容:

当使用一个不应再用于编写新代码的 API 时,可以使用软弃用,但在现有代码中继续使用它仍然是安全的。该 API 保持文档化和测试,但将不再进行进一步开发(没有增强功能)。“软”弃用和(常规的)“硬”弃用的主要区别在于,软弃用不意味着计划移除被弃用的 API。

基本上,软弃用的 API 处于僵尸状态,永远维持存活状态,但将不会有任何进一步的开发工作,并明确建议不再使用它。

optparsegetopt 是两个曾经是解析脚本参数的事实标准解决方案的模块,现在被标记为"软弃用"。你可以永远使用它们,但你可能不应该这样做。

首先,argparse 是更现代的标准库解决方案,我们有一篇很好的文章介绍它

其次,第三方项目如 typerclick 也存在。

Cython 3.0 发布,支持纯 Python 更好

Cython,最著名的 Python 编译器,发布了 3.0 版本。虽然此版本带来了各种改进,但有一个特别突出。Cython 以前一直存在一些限制:它使用 Python 的超集来表达其中的一些功能。

但根据发布说明,这已不再是问题:“现在应该可以用普通 Python 语法来表达所有 Cython 代码并使用所有功能”。

这意味着现在你应该能够使用任何 Python 代码库,只需全部使用 Cython 并观察结果。

PEP 722 - 单文件脚本的依赖规范

尽管无 GIL 话题仍然活跃,但 PEP 722 的提议确实激发了更多的讨论

该提案旨在通过注释中的一种形式化语法,类似于 Groovy 的语法,来表达单个脚本的依赖关系。参考 PEP 本身中的示例:

# In order to run, this script needs the following 3rd party libraries## Requirements:#    requests#    rich

import requestsfrom rich.pretty import pprint

resp = requests.get("https://peps.python.org/api/peps.json")data = resp.json()pprint([(k, v["title"]) for k, v in data.items()][:10])

重要的部分是:

# Requirements:#    requests#    rich

现在这将被正式规范化,以便由第三方工具解析。这个概念并不新鲜,像 pip-run 这样的工具已经支持运行一个脚本,而你可以使用此类注释来描述其依赖关系:

$ pip uninstall rich requestsWARNING: Skipping rich as it is not installed.WARNING: Skipping requests as it is not installed.$ pip-run dah_script.py[│   ('1', 'PEP Purpose and Guidelines'),│   ('2', 'Procedure for Adding New Modules'),│   ('3', 'Guidelines for Handling Bug Reports'),│   ('4', 'Deprecation of Standard Modules'),│   ('5', 'Guidelines for Language Evolution'),│   ('6', 'Bug Fix Releases'),│   ('7', 'Style Guide for C Code'),│   ('8', 'Style Guide for Python Code'),│   ('9', 'Sample Plaintext PEP Template'),│   ('10', 'Voting Guidelines')]

这些包将被安装在临时虚拟环境中,并在运行后被删除,类似于 JS 世界中 npx 的做法。

这个 PEP 并不意味着 Python 或 pip 会集成这样的功能,目前只是在形式上对语法进行规范化。但我对这个提案有很大的希望,因为我有几个独立的 Python 脚本散落在那里,这样的功能对它们会有很大的好处,特别是如果未来可以保留这个虚拟环境。这样的提案可能显示出对此功能的需求,几年后,可能会导致 pip 采纳。例如,npx 影响了 npm create 的添加,允许从特定的包中获取项目模板。事实上,这是 npx 最常见的用例。

Python 在 VSCode 上的支持变得更加快速

如果你使用 VSCode,你可能已经注意到使用许多代码检查器会使 IDE 变得更慢。其中,Mypy 尤为缓慢,因为启动 mypy 命令的速度较慢,并且 VSCode 不使用它的守护进程模式。

但在新版本中,现在有了一个新的官方 mypy 扩展,它使用了 dmypy 守护进程。速度提升非常显著,编辑器现在可以对整个代码库进行检查,而不仅仅是当前文件。

此外,微软官方的 Python 支持扩展 pylance 将会持久化它在第三方库上执行的所有索引工作。这将导致更轻快的启动,对于大型项目而言,由于索引可能需要较长时间,特别是在运行速度较慢的计算机上,这将带来更快的体验。我个人必须在不允许修改的企业客户的笔记本电脑上工作,它们配备了大量的安全软件,这使得它们变得非常缓慢,每次点击任何东西后都会进行进程检查和网络调用来检查文件签名。因此这真是拯救了生命。

在终端中绘制画面

这真是太酷了:

Python 团队官宣下线 GIL

这是一个在终端中运行的画图程序,借助 Python 库 textual 实现。

这可能不会改变你的生活,但太酷了。

我安装了它,反应速度真是快。它甚至可以处理 Ctrl-Z,并且在尝试保存作品时还提供了文件选择器。

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

给TA打赏
共{{data.count}}人
人已打赏
技术教程

MYM支付微信云端一键部署脚本

2024-3-11 18:35:28

技术教程

getMonth()方法

2023-7-23 23:44:38

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索