Requests: 考虑将请求包含在 Python 3.5 的标准库中

是的，因为它简化了整个过程并且不牺牲性能。 所以是的。

• 这会对 Requests 的进化和成长能力产生什么样的影响？
• Requests 的发布频率与 Python 的发布频率一致吗？ 这里的一个很大的不同可能是一个很好的迹象，表明 stdlib 不是请求的正确家园。

让我们抄送一些我们非常关心的人的意见：

@shazow @kevinburke @dstufft @alex @sigmavirus24

“标准库是事物消亡的地方”发生了什么？

发布节奏问题是一个很好的问题； 我会担心失去请求的自由发展能力。 也就是说，请求核心库可能是一个不错的选择。

我的 2 美元货币价值：

我会不愿意这样做。 我认为在标准库之外让我们可以自由地做出有利于我们用户的选择，而不会被核心开发人员的版本支持和发布政策所束缚。 它允许我们尊重地不同意核心开发人员的优先事项。 它使我们能够做出意识形态的决定，这是该项目三年多来的命脉。

我认为现实情况是，如果这个模块进入标准库，当前的核心团队将继续前进。 我当然没有兴趣跟随它进入核心开发的泥潭。 最有可能在 stdlib 中管理请求的是@sigmavirus24 ，而他只是一个人。 随着时间的推移，失去方向将不可避免地导致图书馆界面的侵蚀，我认为这将是一件悲惨的事情。

在标准库中唯一能带给我们的就是时光倒流。 这是将它放在那里的一个很好的理由，如果这是你认为它需要的，但我认为我们不应该假装它会使库或 Python 生态系统变得更好。

我认为您实际上_可以_在没有首先添加 chardet 和 urllib3 或删除对它们的依赖的情况下向 stdlib 添加请求。 还有一个问题是，Python 不想发布 CA 捆绑包，因此您需要对其进行修改，以便它像 Python 现在一样使用系统平台捆绑包。

除此之外，我不确定。 这肯定会使获取请求变得更容易，但是我在 pip 上的部分工作基本上是为了使它易于获取诸如请求之类的东西，而无需将其添加到 stdlib。 最重要的是，在 Python stdlib 中使用多种方法来发出 HTTP 请求也有点令人困惑。 urllib 和 urllib2 的统一在 Python stdlib 中是一件好事，我认为用 urllib.request 和“requests”重新添加它也不是一个好主意。 最后，我认为它实际上不会帮助很多人，这只会进入 3.5+，因此任何想要使用请求的人都必须要么使用 PyPI 上的版本，要么将 3.5 设为我不支持的最低 Python 版本”认为在不久的将来会发生是一件现实的事情。

虽然我认为在标准库中使用 Requests 会帮助新用户，但我不知道它会帮助整个 Python 社区。 有经验的用户知道使用 Requests 并知道如何安装它。

我特别担心它对新开发的寒蝉效应，因为其他人不愿意贡献，因为他们知道很长一段时间内都不会在易于使用的版本中看到他们贡献的更改。

使 Python 发行版默认安装它的中间立场如何？

不，不会。

由于我之前陈述的许多原因，请求绝对不适合包含在 stdlib 中。 单独的 urllib3 依赖是一个完整的showstopper； 我们不希望它死在标准库中。

_将_有用的是添加一些 _basic_ 和类似于建立在 stdlib 当前 http 资源之上的请求，允许用户在不练习血魔法的情况下对 https 执行简单的 get/post 请求。

还要提醒一下，它只会添加到 Python 3 中。 :)（并且不早于 Python 3.6）。

您是否厌倦了维护它 Kenneth？ ;)

我认为我们甚至不能在没有人说 httplib、urllib 和朋友的情况下开始讨论这个问题。 我认为，在不解决选择复杂性的情况下添加请求比“忽略标准库，只使用请求”的答案更糟糕。 这是对 urllib、urllib2 时代的回归。

我认为现实情况是，如果这个模块进入标准库，当前的核心团队将继续前进。 我当然没有兴趣跟随它进入核心开发的泥潭。 最有可能在 stdlib 中管理请求的是@sigmavirus24 ，而他只是一个人。 随着时间的推移，失去方向将不可避免地导致图书馆界面的侵蚀，我认为这将是一件悲惨的事情。

我会走进 stdlib 以尝试提供帮助，但鉴于我不知道我之前提交的补丁集有多少已被接受，而另一个 _reviewed_ 使我担心不想打扰该过程。 我知道核心开发人员完全被更重要的事情所淹没。 我也知道其他人随机决定他们想要维护 httplib/http 但他们显然不适合这项工作（还）而且我没有耐心在@Lukasa和我坐的补丁时处理 httplib周围，​​未经审查，不关心（当他们解决图书馆的紧迫问题时）。

我可能最终只会请求继续使用它。

由于我之前陈述的许多原因，请求绝对不适合包含在 stdlib 中。 单独的 urllib3 依赖是一个完整的showstopper； 我们不希望它死在标准库中。

@kennethreitz （以及整个项目）一直在争论 urllib3 是一个实现细节。 许多请求的最大特性完全由 urllib3 处理，但这并不意味着它们不能被小心地重新实现到真正的无依赖库中。

关于 chardet 依赖性：这对我们（尤其是我）来说只是一个头疼的问题。 它曾经为 py2 和 py3 拥有单独的代码库，直到我将其放入一个单一的代码库库中（仅在最近几个月才合并回 chardet 中）。 图书馆很慢，而且内存很大（这激怒了很多人，以至于在问题跟踪器上对我们大喊大叫）。 它并不完全准确，并且 Mozilla 的通用字符集几乎被 Mozilla 抛弃了。 因此，无论如何，删除 chardet 可能是一个净积极因素。

至于我们是否应该这样做，坦率地说，我并不关心。 stdlib 中的任何内容最终都只会成为 API 中的请求。 Python 3 的采用速度足够慢，我认为人们不会在接下来的 N 年中受到有意义的影响（其中 N 是全球未知的 3.5 年数，用于公司生产）。

就像我说的那样，到时候我可能只会分叉请求或直接使用 urllib3。

前几天我和 Guido 详细讨论了这个问题——chardet 必须首先被包括在内。 我认为 urllib3 和 requests 可以一起包含在 http 包中。

但是，我非常同意@hynek和@dstufft。 也许请求就这样很好:)

无论哪种方式，如果您有想要分享的意见，欢迎您在这里（或任何时候）分享。

:sparkles: :cake: :sparkles:

另外，在没有 asyncio-story 的情况下向 stdlib 添加一个新的 http 模块似乎
对我发疯。

2015 年 1 月 25 日星期日下午 1:15:51，Kenneth Reitz通知@github.com
写道：

无论哪种方式，如果您有想要分享的意见，
欢迎在这里（或任何时候）分享它。

[图像：：闪光：] [图像：：蛋糕：] [图像：：闪光：]

—
直接回复此邮件或在 GitHub 上查看
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
.

我认为我们甚至不能在没有人说 httplib、urllib 和朋友的情况下开始讨论这个问题

这是我的问题。 我认为必须首先理清当前令人困惑的事态。

:+1: :金属:

为了清楚起见，我上面关于重新实现 urllib3 以包含在 stdlib 中的评论不应掉以轻心。 这样做所需的工作量将是巨大的，因为 urllib3 是（可能是 10 年或更长时间）开发人员工作的产物。

几年前，我也曾与 Guido 谈过将 urllib3 放入 stdlib 并得出结论，这不是一个好主意，但在这一点上我相当中立。

几年来，urllib3 的 API 基本上是稳定的，并且几乎完全向后兼容。 它的速度可能比今天的 stdlib 还要慢，绝大多数更改都是小的修复或安全改进（偶尔添加向后兼容的功能，如粒度超时/重试）。 如果有人真的想尝试将 urllib3 纳入标准库，我认为这不是一个糟糕的主意——它只是不是 _best_ 主意。

（我不是在为请求说话，因为它以与 urllib3 不同的目标以非常不同的速度移动。）

在我看来，最好的想法是让 PSF 雇用（或者可能是 Kickstart 或其他什么）1-3 名开发人员在 asyncio 之上构建一个全新的 http 库，支持 HTTP/2，并受 urllib3 的启发，请求，和超。 我很高兴看到尽可能多的代码逐字记录，但以一致、模块化和可重用的方式布局。 理想情况下，目标是 Python 4 或其他东西，并摆脱所有 urllibs 和 httplibs。 我预计这将是 6-9 个月的艰苦工作，但可能更多。

urllib3 最糟糕的部分是它依赖于 httplib，如果有人试图按照@sigmavirus24的建议重写它，我很乐意看到它被替换。 urllib3 的功能在很大程度上受到限制，大量代码用于解决 httplib 的缺点。 虽然如果在这个目标中认真对待 HTTP/2 支持，那么重新实现 HTTP/1.1 的范围将是所需工作的一个非常令人欣慰的部分。

在许多 PyCon 之前，我们中的一些人会面并在白板上设计了一个全新的 http 库的布局，该库将所有部分重构为我们当时可以想象的理想安排。 如果有人要尝试这样做，我很乐意挖掘这些笔记。

+1 @shazow

同样，如果有人发现自己有时间并愿意承担那个相当大的项目，我已经勾勒出一个假定的 API 设计，它可能是一个很好的起点。

是的，因为我将允许请求作为依赖项的唯一方法是它是否在 stdlib 中。

也就是说，urllib3 包含人们真正想要的功能，所以在 stdlib 中拥有它对我来说就足够了

你不使用任何依赖项吗？

@dstufft这是在通常没有的项目中，每个人都不会费心去弄清楚如何使用 urllib。 （人们通常不会因为 ssl/etc 而将其添加为 dep，而是出于懒惰）

@dstufft也多版本 deps 基本上使得很难在库中使用东西。 您可能希望在您的项目中使用请求，如果我们需要它，那么如果版本中发生 API 更改，则可能会受到伤害。

虽然我很欣赏有些人想要开发依赖项而不依赖于多年来没有改变其 API 的其他软件，但这不是讨论的地方。

@sigmavirus24我不同意。 requests 过去曾有过其 API 更改。 API 会发生变化，这就是我们进行版本控制的原因，这也是依赖关系复杂的原因。 这是该讨论的完美案例，因为请求是许多项目的依赖项。

如果您进入标准库，API 必须是稳定的。

@dcramer API 在 1.0 中只中断了一次。 API 确实会发生变化，但请求的 API 也不打算进行任何更改。 我们所做的唯一更改是添加了不会破坏任何内容的json参数。 你可以继续指责我们破坏 API 太多，但是当像 OpenStack 这样的项目长期将需求定义为>=1.2.3时，我认为这说明了请求的稳定性。 API 一直很稳定，正是因为在我们削减 1.0 之后，我们拒绝了 API 的所有新增内容（最近添加了一个明显的例外，即添加了json参数）并且我们非常严格地不破坏 API。 如果您不是请求的消费者，您就不会知道这一点。 所以我不认为你的无知是个人的。

此外，如果 stdlib API 据说如此稳定，请解释为什么 argparse 破坏了 Python 3.3 和 3.4 之间的公共 API？

@sigmavirus24你现在纯粹是把它变成了一场 API 辩论。 我只是指出我不包括它的原因是因为它可以改变，每个人都使用它，每个人都使用不同的版本。 很高兴你们永远不会改变你的 API，但我没有意愿或时间去遵循它或假设那是真的。

你知道 Python 也改变了它的 API，实际上经常，有时以非常重要的方式，也许你听说过 Python 3？

好吧，我要离开这场辩论。 我把我的意见说清楚了。 不知道你们都在抱怨什么。

我认为需要回答的一些关键问题是：

1. 您希望标准文档（包括教程）如何更改？ 当前的标准库 HTTP API 可以追溯到一个时代，在这个时代，抽象出竞争协议（例如 FTP 与 HTTP）的细节被认为是一种理想的方法。 在随后的十五年中，Web 开发社区已将 HTTPS+JSON 作为请求/响应式客户端/服务器交互的首选方法，用于除远程命令执行（使用 SSH 或 Windows RCP）以外的大多数用例，请求 API 是现代 Python 应用程序模型的事实上的标准客户端实现。
2. 您是否希望将请求 API 从事实上的标准升级为法律上的标准，以便它自动包含在所有 CPython 再分发渠道中，得到 CPython（和我们的商业再分发者）长期支持保证的支持，以及所有“仅限标准库”的教育活动？ （后者还是很常见的，因为在企业环境中使用的标准往往包括支持和IP保证，CPython有，但请求没有。在目前的情况下，很多用户根本不会考虑请求作为一个选项，因为对他们来说，获得使用许可的工作量太大了）
3. 标准库中还有哪些其他模块可以通过构建 API 之类的请求来改进？
4. 作为 API 的版本独立实现，保持请求本身不变会更好，而是向标准库添加一个受请求启发的新 API，类似于 Guido 处理 ayncio 标准化工作的方式？

就 PSF 管理开发工作的想法而言，我强烈反对，因为我们没有适当的管理基础设施来处理这类事情。 建议 PSF 为该领域的众筹工作做出贡献的赠款提案将是另一回事（如果没有特定的提案需要审查，则不能保证，但我们当然可以讨论这个想法）。

请注意，一些供应商可能已经重新分发请求，但“他们是否也提供对请求的支持？” 成为我们必须向供应商或平台提供商提出的一个单独问题。 因此，在长期风险管理背景下（想想几年和几十年，而不是几周或几个月），依赖它意味着如果上游感到无聊并转向其他事情，我们要么必须承担自我支持的风险和责任，要么接受我们对平台提供商的选择程度的潜在减少。

对于标准库，我们通常没有这种担忧——虽然再发行商偶尔会破坏一些东西，但在商业环境中，供应商破坏上游工作的东西会给你相当多的影响力来让违规的供应商解决问题。

哦，在自愿实际维护标准库中的东西之前要回答的另一个关键问题：您准备好承担运送软件的责任，该软件有助于为世界上一半的证券交易所提供动力，是企业基础设施最流行的语言之一，一种最流行的科学编程语言（包括用于星际空间任务的轨迹规划），最流行的网络开发语言之一，以及教育机构新计算机扫盲计划中使用的关键语言之一？

您是否也准备这样做，同时让人们在非常低的可靠性水平（通常低于 99% 的正常运行时间）上工作的非关键服务是完全可以接受的抱怨您深刻的信任问题是没有根据的，而只是一个愚蠢的隐藏政治问题他们不会为自己而烦恼吗？

另外，我想纠正一个错误的假设：绝大多数 Python 程序员可能甚至都没有听说过 pip，更不用说请求了。 这些人是在长期支持 Linux 版本的系统 Python 中运行脚本的人，大多数开源开发人员很快就会表达出难以言喻的蔑视，他们没有停下来考虑可能在什么情况下使他们的方法成为一个好主意。

该社区的采用周期时间本质上是以年为单位来衡量的。 目前正在运行足够严格的 CI 以能够更快地运行的行业中只有极少数，而且该部分中的大多数人对放慢足够长的时间不感兴趣，以听取那些拥有大量现有 CI 的人的担忧。我们需要管理和现代化的基础设施。

当我们说“是的，这种方法现在已经足够成熟，我们可以将它或基于它的东西推入标准库以帮助使其成为真正通用的假设”。

作为“开源社区”过滤器泡沫如何扭曲我们观点的一个更具体的例子：Jenkins 在企业 CI 部署中拥有超过 70% 的市场份额。

当您将这种观点基于大量参与开源的个人和组织时，要非常非常谨慎地依赖对“每个人都知道”的直觉。 绝大多数软件开发仍然是定制工作，以满足特定组织的需求，而且绝大多数这样做的人仍然从商业供应商而不是开源社区获取他们的工具和信息。

@dcramer
不知道你们都在抱怨什么。

非常适合这场辩论的语言。 当对你的职位进行合法反击时，你使用了一种贬低女性的诽谤。 不过，这门课程的标准杆。 继续，

@ncoghlan

关于第 1 点：我认为使用 stdlib 中的请求（类似请求）会大大简化文档。 在学习一门新语言时，我做的第一件事就是弄清楚 HTTP 是如何工作的。 无论如何，拥有该特色是指南将受益的东西。

关于第 2 点：API 和库之间存在差异，即事实上的与法律上的。 API 可以很容易地由标准库提供。 我认为您对支持的关注将更多地针对包含的请求（代码）。

关于第 3 点和第 4 点：我不确定这是要在这里讨论的内容。 也许python-ideas会更好。

就 PSF 管理开发工作的想法而言，我强烈反对，因为我们没有适当的管理基础设施来处理这类事情。

那很有意思。 我不认为这是一个概率，但是拥有比 http(lib) 更好的东西会很棒。

对于标准库，我们通常没有这种担忧——虽然再发行商偶尔会破坏一些东西，但在商业环境中，供应商破坏上游工作的东西会给你相当多的影响力来让违规的供应商解决问题。

我不确定你说的杠杆是什么。 我已经看到 Debian 和 CPython 中的其他重新分发器破坏了 ensurepip、venv 和其他东西。 不过，这与本次讨论无关。

哦，在自愿实际维护标准库中的东西之前要回答的另一个关键问题：您准备好承担运送软件的责任，该软件有助于为世界上一半的证券交易所提供动力，是企业基础设施最流行的语言之一，一种最流行的科学编程语言（包括用于星际空间任务的轨迹规划），最流行的网络开发语言之一，以及教育机构新计算机扫盲计划中使用的关键语言之一？

如前所述，目前参与的大多数人都不会继续该项目。 我可能是唯一的人，但鉴于我在上游 CPython 开发方面的往绩，将这种负担留给现有（和其他未来）核心开发人员不会有成效。

当我们说“是的，这种方法现在已经足够成熟，我们可以将它或基于它的东西推入标准库以帮助使其成为真正通用的假设”。

现实是，那些人永远也赶不上，不是吗？ 人们仍然在 Python 2.4 和 2.5 上运行软件。 F5 的负载均衡器仍然只支持 Python 2.5。 2.7 可能会一直使用到我的自然生命结束（我希望会很长）。 这些人真的是这个决定最会影响的人吗？ 你描述的那些人可能永远不会飞跃到 Python 3。目前，它仍然是一个 _leap_。 也许当他们决定考虑它时，Python 3.8 或 3.9 或 4.2 将会发布并且对他们来说麻烦会少得多。

是的，我的主要观点是标准库包含的目标与提供开源库供其他开源开发人员使用的更常见任务的目标非常不同。 如果请求团队选择继续仅提供独立维护的库（我非常感谢社区服务，你们做得很好！），并且不支持推动 API 的标准化，那么我们将依赖在 RHEL/Fedora/CentOS、Debian/Ubuntu、ActiveState、Enthought 和 Continuum Analytics 等再发行商上获取模块并对其进行标准化_无论如何_，这样人们就可以假设它总是可用的（或者至少经常足以让他们很高兴在未使用适当的依赖声明完全打包的单文件脚本中依赖 API）。 但是，大多数介绍性文档可能仍会引导人们以标准库方式执行 HTTP，因此人们是否会学习“Python 的 HTTP，2001 版”或“Python 的 HTTP，2015 版”将取决于他们是否从“仅限标准库”源，或包含推荐的第三方模块的源。

就像 virtualenv 和 PEP 405 一样，或者 Twisted+Tornado vs asyncio，或者 ipaddr vs ipaddress，我认为在标准库中包含 _requests 本身是没有意义的。 相反，我认为支持包含 requests _inspired_ API 更有意义，该 API 忽略了所有跨版本兼容性代码、证书捆绑等，并简单地提供了用于处理 2015 年之前经过身份验证的 HTTP 请求的默认 API 和文档标准。 然后在 2030 年，我们将抱怨 _requests_ API 设计按照 2030 年标准是多么陈旧（“HTTP？谁还使用它？！？！”），但没关系，这就是这些循环的工作原理（直到第一个 AJAX然后 JSON 出现了，XML-RPC 是山中之王）。 如果在人们开始抱怨它过时之前，你已经完成了 5 年的 API 设计，那么你做得很好，10 年令人印象深刻，而 15 年真的很壮观。

启动该过程所需的主要事情是一个有充分动机的人，即让请求 API 随处可用，以支持标准化工作，完成实施工作，并致力于至少在 stdlib 的前几年进行维护。 另一种选择是继续严重依赖再发行商来接触不愿意和/或无法从互联网下载和运行任意代码的开发人员（这一类别包括任何行业中具有严格监管尽职调查要求的所有人，以及任何人为风险偏好同样低的其他组织工作）。

关于其他一些要点，目前对 Debian 的影响相对较弱，而在商业支持的再分发中，这种影响更好，付费客户可以直接抱怨与我们作为上游开发社区设定的期望相比被破坏的事情。

在更新周期方面，上游标准化（即使在 Python 3 中）传达的关键内容之一是社区共识。 在那一点上，作为 Python 3 功能“反向移植”的库变得更容易证明与 Python 2 捆绑的合理性。我个人仍然希望看到 Python 2 的相扑版本，它完全可以进行这种捆绑（unittest2、subprocess32、enum34、contexlib2 、金银花等），但这本身就是一场完全独立的政治斗争，尤其是在说服人们在 2020 年之前真正有兴趣和资源来维持这种独立于再发行商的相扑发行。

@dcramer感谢您给我们您的时间 - 真的很感激 :heart:

@sigmavirus24一切都很好:)

除了 stdlib 包含方面，我没有太多要添加的内容
看看一些 PEP 或线程或谈论应该做什么会很好
在 Python 标准库中，也许回顾过去一年左右的时间
从“如何处理这个问题”的角度来看发展
如果这是标准库中的模块，则不同”。

因为这可能成为人们说的事实上的线索
“在考虑将请求添加到 stdlib 时，我们应该添加/更改什么”，
我想再次呼吁更新异常层次结构。 一世
当请求失败时通常有两个问题 - a) 什么是
影响？ b) 我可以安全地重试请求吗？
DNS 查找失败和管道损坏具有非常不同的含义，
但请求当前将两者都分组为 ConnectionError。 我详细介绍了一些
这里涉及的工作：
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

很高兴与感兴趣的人讨论更多。

凯文·伯克
电话：925.271.7005 | 二十毫秒.com

在 2015 年 1 月 25 日星期日晚上 8:15，ncoghlan [email protected]写道：

作为“开源社区”如何过滤的一个更具体的例子
泡沫会扭曲我们的观点：詹金斯拥有超过 70% 的市场份额
在企业 CI 部署中。

非常非常谨慎地依赖对“每个人”的直觉
知道”，当你基于个人和
大量参与开源的组织。 绝大部分
的软件开发仍然是定制工作，以满足一个人的需要
特定的组织，而绝大多数这样做的人是
仍然从商业供应商那里获取他们的工具和信息，而不是
比开源社区。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71413074
.

FWIW，我认为http://docs.python-requests.org/en/latest/dev/philosophy/上的措辞，

Essentially, the standard library is where a library goes to die.
It is appropriate for a module to be included when active 
development is no longer necessary.

可能会被误解。 对我来说，这听起来像是对标准库的贬义态度，标准库当然不包括死库。 我很生气，并没有使用请求，直到我点击这个页面，这是一个有趣的讨论，比上面的措辞要好得多。