哈Ha！ 我向您介绍了Glyph Lefkowitz（Twisted框架的创建者）撰写的
Toward的“走向Python内核”的翻译。
更多细节-在削减。
最小化标准库的魔力
在
Amber Brown上个月在Python语言峰会上的
演讲的影响
下 （指她5月的报告“电池在打开，但是它们正在泄漏”-翻译评论），Christian Hymes继续
致力于减少标准Python库的
工作 ，并创建了一个
PEP 594建议以明确删除它的过时和不受支持的片段。
PEP 594（“从标准库中取出废旧电池”）的出现对于蟒蛇人来说是个好消息，尤其是那些支持标准库并且现在工作量较小的人。 简短介绍一下PEP库中已过时或基于删除的模块，这是不言而喻的（我个人最喜欢sunau，xdrlib和chunk模块）。 标准的Python库包含许多有用的模块，但是，它还包括一个真实的代码墓地，一个废弃片段的高耸的纪念碑，有可能随时掩埋其开发人员。
但是，我认为可能会在此PEP语句中采用错误的方法。 CPython开发人员目前同时支持标准库。 遗漏了大笔钱，希望它有朝一日能使某人受益。 在前面提到的PEP中，在保护colorsys模块时可以遵循此原理。 为什么不删除它？ 答：“需要此模块才能在坐标系（RGB，YIQ，HSL和HSV）之间转换CSS颜色。 [他]没有在核心开发上增加额外的成本。”
有时候，互联网访问受到限制，预装大量材料可能是一个不错的主意，但是如今，在不同坐标系之间转换颜色所需的模块距离pip install命令仅一步之遥。
你为什么不考虑我的游泳池要求？
因此，让我们看一下这句话：colorsys之类的微型模块是否会“增加核心开发成本”？
对于主要开发人员而言，他们试图维护一个庞大而古老的C代码基础（即CPython本身）就足够了。 正如Marietta Viggia在北湾Python
演讲中所说，内核开发人员最常问的问题是：“为什么不查看我的池请求？” 答案是什么？
忽略这些池请求更容易。 这就是成为内核开发人员的意义！
可能有人会问，Twisted是否有同样的问题？ Twisted也是大量松散耦合模块的集合。 一种用于联网的标准库。 所有这些用于SSH，IMAP，HTTP，TLS等的客户端和服务器。 等 试图将所有东西都压缩到一个包中？
被迫回答：
是的 。 Twisted是整体的，因为它来自与CPython相同的历史时期，当时组件安装确实非常复杂。 因此，我同意CPython的立场。
理想情况下，在某个时候，Twisted中的每个子项目都应该成为一个单独的项目，该项目具有自己的存储库，持续集成（CI），网站，当然还有自己更专注的开发人员。 我们已经在缓慢但确定地共享可以绘制自然边界的项目。 从Twisted开始的一些要点（不断且渐进）被分离，延迟和文件路径处于分离过程中。 其他项目，例如klein和treq，继续单独存在。 当我们发现如何降低设置和支持持续集成的成本以及如何为每个平台释放基础架构时，我们将做更多的事情。
但是，Twisted的整体性质是该项目最紧迫甚至最严重的问题吗？ 让我们欣赏它。
在撰写本文时，Twisted有5个未解决的未决缓冲池请求符合要求。 大致而言，花在考虑机票上的平均时间为四天半。 队列中最早的票证日期为4月22日，这意味着自发送最早的未审查池请求以来已经过了不到2个月的时间。
总是很难找到足够的开发人员和时间来响应池请求。 有时似乎我们仍然经常遇到这样的问题：“为什么不考虑我的游泳池申请？” 我们并不总是做到完美，但总的来说，我们可以做到； 在最不幸的月份，队列在0到25之间波动。
与这些数字相比，CPython的核心呢？
访问github后 ，您可以看到目前有429张门票正在等待考虑。 他们中最老的有望从2018年2月2日开始，即将近500天。
解释器有多少问题，stdlib库有多少问题？ 显然，等待审核是一个问题，但是删除stdlib会有所帮助吗？
为了进行快速而不科学的评估，我查看了池请求的第一页（最旧的页面）。 在我的主观评估中，在25个池请求中，有14个与标准库相关，有10个与语言或解释程序的核心相关，还有一个与一个小的文档问题相关。 根据这个比例，我敢建议在未审查的池请求中大约有一半与标准库代码相关联。
因此，主要的CPython团队需要停止支持标准库的第一个原因是，因为他们
实际上没有能力支持标准库。 或者，换句话说，他们
不支持它，只是保留它并开始分享工作而已。
事实是，没有CPython开放池请求与colorsys模块相关联。 确实，它不增加开发内核的成本。
内核开发本身会带来这些成本。 如果我想更新colorsys模块以跟上时代的发展（也许有一个Color对象，也许支持整数颜色模型），那么我很可能必须等待500天或更长时间。
结果，更难更改标准库中的代码，这导致用户的贡献兴趣降低。 不频繁发布的CPython还会减慢库的开发速度，并降低用户反馈的好处。 几乎没有标准库的所有模块都积极支持第三方替代方案，这并不是巧合，这不是stdlib开发人员的错。 除了最常用的stdlib模块之外，整个过程都经过了改进，以使其停滞。
新环境，新要求
也许更为重要的是，与其他语言实现相比，将CPython链接到标准库使CPython本身处于特权位置。
播客之后的
播 客 （即
报告之后的
播 客）告诉我们，为了继续取得成功并开发Python，您需要在新领域中发展，尤其是在前端以及移动客户端，嵌入式系统和控制台游戏中。
这些环境需要一个或两个条件：
在所有这些情况下，绊脚石是必须从标准库中删除的模块的定义。 需要通过反复试验找到它们。 首先，该过程与Python应用程序中的标准依赖项确定过程完全
不同 。 在setup.py中没有install_requires声明，该报告报告该库使用stdlib中的模块，由于空间限制，目标Python运行时可能会跳过该模块。
即使我们使用的所有东西都是Linux安装上的标准Python，也会出现问题。 甚至用于服务器和台式计算机的Linux发行版都同样需要较小的Python内核程序包，因此标准库在其中已经被截断了。 这可能无法满足Python代码的要求，因此，即使
pip安装无法正常工作，也会导致错误。
全部拿走
“假设您每天需要清洁一点呢？ 尽管听起来令人信服，但不要让自己被欺骗。 在您看来清洁永远不会结束的原因恰恰是因为您要清洁一点。 [...]成功的主要秘诀是：如果一口气将其移除，而不是逐步将其移除，那么您就可以永久改变自己的思维和生活习惯”
玛丽·近藤（Marie Kondo），神奇清洁。 《恢复家庭和生活秩序的日本艺术》（第15-16页）
虽然逐步缩减标准库是朝着正确方向迈出的一步，但仅凭逐步改变是不够的。 正如Marie Kondo所说，如果您真的想整理事物，那么第一步就是要使
所有东西都看不到 ，以便真正看到一切，然后只返回需要的东西。
现在该向不再鼓舞人心的模块表示敬意，并向他们发送很长的路要走。
我们需要一个仅包含最基本要求的最低版本的Python，以便所有实现都可以保持一致，以便应用程序（即使是那些在Web浏览器或微控制器中运行的应用程序）可以简单地在requirements.txt中声明其要求。
在某些业务环境中，拥有巨大的标准库的想法似乎很有吸引力，因为在requirements.txt中添加依赖关系是官僚的，但是，在这种环境中的“标准库”具有纯粹的任意界限。
为CPython的某些二进制发行版（甚至可能是官方发行版）提供许多来自PyPI的模块，可能仍然是一个好主意。 实际上，即使对于普通任务，也需要一定数量的stdlib库，该pip需要安装其他必要的模块。
现在有一种情况，其中pip与Python一起分发，但未在CPython存储库中
开发 。 默认Python安装程序随附的部分内容是在CPython存储库中开发的，另一部分是用于解释程序的单独的tarball。
要使用Linux，我们需要具有大量其他程序的可启动媒体。 但这并不意味着Linux内核本身就位于一个庞大的存储库中，一个团队可以在其中开发运行Linux服务器所需的数百个应用程序。 Linux内核非常有价值，但是使用Linux内核的操作系统是Linux内核与各种单独开发的库和程序的
结合而创建的。
结论
“包含电池”的理念非常适合其创建； 就像助推火箭一样，它将Python交付给编程人员。 但是，随着开源生态系统和Python软件包的成熟，此策略已过时，并且像任何加速器一样，我们必须让它回到地面，以免将我们拖回原处。
新的Python运行时，新的部署任务和新的开发人员受众都为Python社区提供了达到新高度的巨大机会。
但是要实现这一目标，我们需要一个新的，更紧凑且不重载的Python内核。 我们需要将整个标准库摇到地板上，只剩下我们需要的最小部分，以便我们可以说：这确实是必要的，但是很高兴。
我希望我至少已经说服了我们中的某些Python核心。
现在：谁想写
PEP ？