11 KiB
Python 新闻:2022 年 1 月有什么新消息
在 2022 年 1 月的**，代码格式化程序布莱克看到了它的第一个非测试版本，并发布了一个新的稳定性政策。 IPython ，强大的交互式 Python shell，标志着版本 8.0 的发布，这是其三年来的第一个主要版本发布。此外， PEP 665 ，旨在通过指定锁文件的格式使可复制的安装更容易，被拒绝。最后但同样重要的是，Python 中一个 15 年前的内存泄漏 bug 被修复。**
让我们深入了解过去一个月最大的 Python 新闻故事！
免费奖励: 并学习 Python 3 的基础知识，如使用数据类型、字典、列表和 Python 函数。
不再黑贝塔
固执己见的代码格式器 Black 的开发者现在有足够的信心称最新版本是稳定的。此次发布首次将 Black 带出测试版:
代码格式可能是开发人员之间大量冲突的根源。这就是为什么代码格式化程序，或者说 linters ，有助于执行风格约定，以保持整个代码库的一致性。Linters 建议更改，而代码格式化程序重写您的代码:
这使您的代码库更加一致，有助于及早发现错误，并使代码更容易扫描。
YAPF 是格式化程序的一个例子。默认情况下，它带有 PEP 8 风格指南，但它并不固执己见，给你很多对其配置的控制。
Black 走得更远:它带有 PEP 8 兼容风格，但总的来说，它是不可配置的。不允许配置背后的想法是，通过放弃对风格的控制，您可以解放您的大脑，专注于实际的代码。许多人认为这种限制给了他们更多的自由去成为有创造力的程序员。但是当然，并不是所有人都喜欢放弃这种控制权！
像布莱克这样固执己见的格式化者的一个重要特征是，他们让你的差异更具信息性。如果你曾经向你的版本控制系统提交过清理或格式化的提交，你可能已经无意中污染了你的 diff。
使用可配置的格式化程序，或者不使用格式化程序，在项目中途更改或实施样式会使功能代码的更改难以跟踪。这是因为差异会带来风格上的变化和功能上的代码变化，这可能需要很长时间才能理清。
但是，如果您在整个项目中使用黑色，那么您可以确信您的 diff 将只显示功能性的代码更改。
随着 Black 的第一个稳定发布，一个新的稳定政策也随之而来，它旨在明确你可以从 Black 的稳定发布中期待什么。
稳定性策略主要关注如何处理格式更改。Python 在不断发展，偶尔 Black 对自己的风格做一点小小的改变也是有意义的。稳定性政策将阻止 Black 在给定的日历年内进行此类更改。
稳定性策略保证，在给定的一月中，任何用黑色格式化的代码将在该年的十二月中产生完全相同的输出，而不管黑色的任何内部变化。黑色的版本号也与年份相关联，因此版本 22 对应于 2022 年期间的黑色。当 2023 年到来时，布莱克将发布第 23 版。如果有任何样式的改变，它们将会在 23 版中应用，而不是之前。
黑色已经相当受欢迎，这个新的稳定版本可能会增加它的采用。
IPython 8.0 的发布
在 IPython 7.0 发布三年后，本月发布了 IPython 8.0。这个新版本反映了大量的协作努力，包含了 250 多个拉取请求。主要亮点是默认的黑色格式、改进的回溯和改进的建议。
IPython 是由费尔南多·佩雷斯在 21 世纪初创建的，据说是在他拖延大学学业的时候。IPython 的核心是一个交互式 shell，可以用来替代 Python 的默认 REPL。它包括诸如语法高亮、自动建议和代码完成等便利功能:
IPython 被用作 Jupyter Notebook 的 Python 内核，这是一个以类似文档的格式显示代码执行的程序。科学家和教育工作者经常使用它以更广为人知的格式显示 Python 代码，包括优雅的输出或富文本格式:
有关 Jupyter 功能的更多信息，请查看Jupyter 笔记本简介。
从开发人员的角度来看，开发最新版本的最重要的工作之一是关注代码库的精简。这一努力得到了回报，将代码库从 348 个文件的 37，500 行代码减少到 294 个文件的 36，100 行代码！
该版本还发布了一个关于经验教训的总结，其中包含了一些给开发者的智慧之言。
PEP 665 -被拒绝
PEP 665 本月被指导委员会否决。这个有点争议的 PEP 旨在使 Python 的可复制安装更加容易。
大多数包管理器都有一个锁文件。Python 生态系统中的一个这样的文件是 poetry.lock文件，你可以在诗歌中找到它。 Pipenv 也有自己的锁文件。
你可以把一个锁文件想象成一个更加详细的 requirements.txt 文件。它更详细地介绍了用于安装的确切文件、版本甚至安装程序。锁定文件有助于跨环境、大型团队或用户群进行可重复的设置。PEP 665 旨在标准化锁文件格式。
关于更详细的讨论，请查看 PEP 作者、Python 核心开发者 Brett Cannon 的真实 Python 播客第 93 集。这个播客是在 PEP 被否决之前录制的。
根据批评者的说法，这个 PEP 有所欠缺，因为它要求所有的包都作为轮分发，并且留下了一些关于如何准确处理列表(源代码分发)包的疑问。有关轮子和目录的更多详细信息，请查看什么是 Python 轮子，为什么要关注？
在播客中，Brett Cannon 将 Python 称为“世界的粘合代码”，这要归功于 Python 能够整合来自其他语言的库，如 C、Go 和 Rust。当安装一个依赖于其他语言的包时，Python 有很多工作要做，以确保一切设置正确。这项工作并不总是成功的，这给 Python 社区带来了一些挫折。
编写 PEP 665 是为了解决安装的棘手问题，以及在不同系统上安装略有不同的缺陷。虽然它被否决了，但在这个问题上仍有许多工作要做。一些相关的 pep 有:
我们在 Real Python 要特别感谢 Brett Cannon，他也是 PEP 621 和 PEP 650 的作者，感谢他在这一领域的持续努力。
至少现在，Python 不会标准化一个锁文件格式，而像 poem 和 Pipenv 这样的工具将继续拥有它们自己的版本。
你想看看标准化的锁文件吗？您在复制安装时遇到过问题吗？我们很想在下面的评论中听到你的意见！
十五岁的 Bug，修复！
维克多·斯丁纳表现出非凡的坚韧，他将一个15 岁的臭虫标记为“已修复”。
这个 bug 是由 Ben Sizer 在 2007 年提出的，显示 Python 在退出时有一个内存泄漏。也就是说，Python 不会释放它已经使用的所有内存。就像当处理文件时你应该如何关闭文件对象一样，程序应该在不再需要内存时释放内存。
由于这是各种程序相对常见的问题，操作系统通常会在应用程序退出后自行清理。自动清理意味着这个内存泄漏错误的影响相对较小，不会影响大多数用户。然而，对于启动许多 Python 子进程的程序来说，这是一个问题，正如错误报告中发布的演示 C 程序所示:
#include <Python.h> int main(int argc, char *argv[]) { Py_Initialize(); Py_Finalize(); Py_Initialize(); Py_Finalize(); Py_Initialize(); Py_Finalize(); Py_Initialize(); Py_Finalize(); Py_Initialize(); Py_Finalize(); Py_Initialize(); Py_Finalize(); Py_Initialize(); Py_Finalize(); }
这个程序多次启动和结束 Python，导致越来越多的未释放引用，这代表了内存泄漏。要了解更多关于内存和内存管理的知识，请查看 Python 中的内存管理。
这些泄密范围很广，来自几个不同的来源。经过了无数次的修改和十五年(！)将 bug 减少到值得将其标记为“已修复”的程度仍然有一些内存泄漏，但现在已经足够好了。谢谢你，维克多·斯坦纳！
Python 的下一步是什么？
一月份你最喜欢的 Python 新闻是什么？我们错过了什么值得注意的吗？请在评论中告诉我们，我们可能会在下个月的 Python 新闻综述中介绍您。
快乐的蟒蛇！**