Requests: Python3.5の標準ライブラリにリクエストを含めることを検討してください

はい。プロセス全体が簡素化され、パフォーマンスが犠牲にならないためです。 あ、はい。

• これは、リクエストの進化と成長の能力にどのような影響を及ぼしますか？
• Requestsのリリース頻度はPythonのリリース頻度と一致しますか？ ここでの大きな違いは、stdlibがリクエストの適切なホームではないことを示す良い兆候かもしれません。

私たちが強く関心を持っている意見を持っている人たちをCCしましょう：

@shazow @kevinburke @dstufft @alex @ sigmavirus24

「標準ライブラリは物事が死ぬ場所です」はどうなりましたか？

リリースケイデンスの質問は良い質問です。 リクエストが自由に進化する能力を失うのではないかと心配です。 そうは言っても、おそらくリクエストコアライブラリが適しているでしょう。

私の2 $ CURRENCYの価値：

私はそれをするのを嫌がるでしょう。 標準ライブラリの外にいることで、バージョンのサポートとリリースに関するコア開発者のポリシーにとらわれることなく、ユーザーに役立つ選択を自由に行えるようになったと思います。 これにより、コア開発者の優先順位に敬意を表して反対することができます。 そしてそれは私達が3年以上このプロジェクトの生命線であったイデオロギー的な決定をすることを可能にします。

このモジュールが標準ライブラリに入ると、現在のコアチームはそこから先に進むのが現実だと思います。 私は確かにそれをコア開発者である泥沼に追い込むことにほとんど興味がありません。 stdlibでリクエストを管理する可能性が最も高いのは@ sigmavirus24で、彼はたった1人です。 その方向性の喪失は、必然的に図書館のインターフェースの侵食につながるでしょう、そしてそれは悲劇的なことだと思います。

標準ライブラリにあることだけが私たちに与えるのは、私たちの時間です。 それが必要だと思うなら、それはそこに置くのに十分な理由ですが、それがライブラリやPythonエコシステムをさらに良くするふりをするべきではないと思います。

最初にchardetとurllib3を追加するか、それらへの依存関係を削除せずに、実際にstdlibにリクエストを追加できるとは思いません。 PythonがCAバンドルを出荷したくないということもあるので、Pythonが現在自然に行っているように、システムプラットフォームバンドルを使用するように変更する必要があります。

それに加えて、私にはわかりません。 確かにリクエストを取得しやすくなりますが、pipに関する私の作業の一部は基本的にそれを作成することであるため、stdlibに追加しなくてもリクエストなどを簡単に取得できます。 その上、PythonstdlibでHTTPリクエストを作成する複数の方法があることもやや混乱します。 urllibとurllib2の統合はPythonstdlibで良いことであり、urllib.requestと "requests"でそれを再度追加することも良い考えではないと思います。 最後に、実際には多くの人に役立つとは思いません。これは3.5以降にしか適用されないため、リクエストを使用したい人は、PyPIにあるバージョンを使用するか、3.5をサポートされている最小のPythonバージョンにする必要があります。近い将来に起こる現実的なことだと思います。

標準ライブラリにリクエストがあると、新しいユーザーに役立つと思いますが、Pythonコミュニティ全体に役立つかどうかはわかりません。 経験豊富なユーザーは、リクエストの使用方法とインストール方法を知っています。

私は特に、他の人が貢献することを嫌がり、使いやすいリリースで彼らの貢献した変更を長い間見ないことを知っているので、それが新しい開発に与える萎縮効果に関心があります。

Pythonディストリビューションをデフォルトでインストールして出荷することの中間点はどうですか？

いいえ、そうではありません。

私の前に述べた多くの理由から、リクエストはstdlibを含めるにはまったく不適切です。 urllib3の依存関係だけでも、完全なショートッパーです。 stdlibで死なないようにします。

便利なのは、stdlibの現在のhttpリソースの上に構築されたリクエストに似たものを追加することです。これにより、ユーザーはブラッドマジックを実行せずにhttpsへの簡単なget / postリクエストを実行できます。

また、Python3にのみ追加されることをお知らせします。 ：）（Python 3.6より前ではありません）。

ケネスを維持するのにうんざりしていませんか？ ;）

httplib、urllib、および友人がどうなるかを誰かが言わずに、この質問について話し合うことすらできないと思います。 選択の複雑さに対処せずにリクエストを追加することは、「stdlibを無視し、リクエストを使用する」という答えよりも悪いと思います。 これは、urllib、urllib2の時代への回帰です。

このモジュールが標準ライブラリに入ると、現在のコアチームはそこから先に進むのが現実だと思います。 私は確かにそれをコア開発者である泥沼に追い込むことにほとんど興味がありません。 stdlibでリクエストを管理する可能性が最も高いのは@ sigmavirus24で、彼はたった1人です。 その方向性の喪失は、必然的に図書館のインターフェースの侵食につながるでしょう、そしてそれは悲劇的なことだと思います。

私はstdlibに迷い込んで助けようとしましたが、提出した以前のパッチセットの数がわからないという事実を考えると、もう1つは「レビュー済み」であるため、そのプロセスに煩わされることを警戒しています。 コア開発者はもっと重要なことに完全に圧倒されていることを私は知っています。 他の誰かがhttplib / httpを維持したいとランダムに決定したことも知っていますが、彼らは明らかにその仕事には適していないので、 @ Lukasaと私の両方が座っているパッチのときにhttplibで作業する忍耐力がありません周りにあり、レビューされておらず、気にされていません（ライブラリの差し迫った問題を修正するとき）。

私はおそらくそれを使い続けるためにリクエストをフォークするだけになるでしょう。

私の前に述べた多くの理由から、リクエストはstdlibを含めるにはまったく不適切です。 urllib3の依存関係だけでも、完全なショートッパーです。 stdlibで死なないようにします。

urllib3が実装の詳細であるということは、常に@kennethreitz （したがってプロジェクト全体）の論争でした。 リクエストの最大の機能の多くは完全にurllib3によって処理されますが、真に依存関係のないライブラリに注意深く再実装できなかったという意味ではありません。

シャルデットの依存関係について：それは私たち（そして特に私にとって）にとって頭痛の種に過ぎませんでした。 単一のコードベースライブラリに入れるまでは、py2とpy3に別々のコードベースがありました（これは過去数か月でのみchardet本体にマージされました）。 ライブラリは遅く、大量のメモリを大量に消費します（これは、多くの人を怒らせて、ここで課題追跡システムで私たちに怒鳴りつけます）。 それは完全に正確ではなく、それがモデル化されたMozillaのユニバーサルチャートは、Mozillaによってほとんど放棄されました。 したがって、シャルデットを削除することは、とにかく正味のプラスになるでしょう。

これをすべきかどうかについては、率直に言って無関心です。 stdlibにあるものはすべて、APIのみのリクエストになります。 Python 3の採用率は十分に遅いので、今後N年間（Nは企業が本番環境で使用する3.5の世界的に未知の年数）、これによって人々が有意義な影響を受けることはないと思います。

そして、私が言ったように、私はおそらくその時点でリクエストをフォークするか、urllib3を直接使用することになります。

先日、Guidoとこれについて詳しく話し合いました。最初に、chardetを含める必要があります。 urllib3とリクエストを一緒にhttpパッケージに含めることができると思います。

しかし、私は@hynekと@dstufftに同意する

いずれにせよ、共有したい意見がある場合は、ここで（または実際にはいつでも）共有できます。

：sparkles ：： cake ：： sparkles：

また、非同期ストーリーなしでstdlibに新しいhttpモジュールを追加するようです
私にボンカー。

2015年1月25日午後1時15分51秒ケネスライツ[email protected]
書きました：

いずれにせよ、あなたが共有したい意見を持っているなら、あなたは
ここで（または実際にはいつでも）共有することを歓迎します。

[画像::スパークル：] [画像::ケーキ：] [画像::スパークル：]

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
。

httplib、urllib、および友達がどうなるかを誰かが言わずに、この質問について話し合うことすらできないと思います。

これが私の問題です。 私は、現在の混乱している状況を最初に整理する必要があると思います。

：+1 ：： metal：

明確にするために、stdlibに含めるためにurllib3を再実装することについての私の上記のコメントは軽視されるべきではありません。 urllib3は（おそらく10年以上の）開発者の作業の産物であるため、これを行うために必要な作業量は膨大になります。

私も数年前にurllib3をstdlibに投げ込むことについてGuidoと話しましたが、それは素晴らしいアイデアではないという結論に達しましたが、現時点ではかなり中立です。

urllib3のAPIはほぼ安定しており、ここ数年はほぼ完全に下位互換性があります。 そのペースは、今日のstdlibのペースよりもさらに遅い可能性があり、変更の大部分はマイナーな修正またはセキュリティの改善です（きめ細かいタイムアウト/再試行などの下位互換性のある機能の追加が時折あります）。 誰かが本当にurllib3を標準ライブラリに入れようと思ったのなら、それはひどい考えではないと思います。それは単に_最良の_考えではありません。

（それはurllib3とは異なる目標で非常に異なるペースで動くので、私はリクエストについて話していません。）

私の意見では、PSFが1〜3人の開発者を雇って（またはキックスタートなど）、urllib3からの多大なインスピレーションを受けてHTTP / 2をサポートするasyncioの上に新しいhttpライブラリを構築するのが最善のアイデアです。 、およびハイパー。 できるだけ多くのコードが逐語的に解釈され、一貫性があり、モジュール式で、再利用可能な方法でレイアウトされているのを見てうれしいです。 理想的にはPython4か何かをターゲットにして、すべてのurllibとhttplibを取り除きます。 これは6〜9か月のハードワークになると思いますが、それ以上になる可能性があります。

誰かが@ sigmavirus24の提案

多くのPyConsの前に、私たちの多くが出会い、すべてのピースを当時想像できる理想的な配置にリファクタリングする新しいhttpライブラリのレイアウトをホワイトボードに載せました。 誰かがこれを試みるつもりなら、私はこれらのメモを掘り下げてうれしいです。

+1 @shazow

繰り返しになりますが、そのかなり大きなプロジェクトに取り組む時間と傾向に気付いた人がいたら、私は良い出発点となる可能性のある推定API設計をスケッチしました。

はい。依存関係としてリクエストを許可する唯一の方法は、stdlibにある場合です。

とは言うものの、urllib3には人々が本当に望んでいる機能が含まれているので、stdlibにそれを含めるだけで十分です。

依存関係を使用しませんか？

@dstufftこれは、一般的には行われないプロジェクトであり、誰もがurllibの使用方法をわざわざ理解することはできません。 （一般的にssl / etcのために、人々はそれをdepとして追加していませんが、怠惰からです）

@dstufftはまた、マルチバージョンのdepsにより、基本的にライブラリでの使用が困難になります。 プロジェクトでリクエストを使用することをお勧めします。必要な場合は、バージョンでAPIの変更が発生すると、世界が傷つく可能性があります。

何年もAPIを変更していない他のソフトウェアに依存せずに依存関係を開発したいと思っている人もいますが、ここでは議論の場ではありません。

@ sigmavirus24同意し

stdlibに移動する場合、APIは安定している必要があります。

@dcramer APIは、1.0で1回だけ壊れました。 APIは変更されますが、リクエストのAPIも変更を計画していません。 私たちが行った唯一の変更は、何も壊さないjsonパラメーターを追加することです。 APIを壊しすぎていると非難し続けることはできますが、OpenStackのようなプロジェクトで長い間>=1.2.3として定義された要件がある場合、それはリクエストの安定性について多くを語っていると思います。 APIは安定しています。これは、1.0をカットした後、APIへの新しい追加をすべて拒否し（ jsonパラメーターを追加するという最近の明らかな例外を除く）、APIを壊さないように非常に厳格になっているためです。 あなたがリクエストの消費者でないなら、あなたはこれを知らないでしょう。 だから私はあなたの無知を個人的には受けません。

さらに、stdlib APIが非常に安定していると思われる場合は、argparseがPython3.3と3.4の間でパブリックAPIを壊した理由を説明してください。

@ sigmavirus24あなたは今、これを純粋にAPIの議論に変えています。 含めない理由は、変更される可能性があり、誰もが使用し、誰もが異なるバージョンを使用しているためです。 APIを変更しないのは素晴らしいことですが、私はそれに従うことや、それが真実であると想定することを望んでいません。

PythonがAPIも変更することをご存知ですか？実際には、非常に大きな方法で、時にはPython 3について聞いたことがあるかもしれませんが、実際にはかなり頻繁に変更されます。

さて、私はこの議論を残しています。 私は自分の意見を明確にしました。 あなたが何について愚痴を言っているのかわからない。

答えるべきいくつかの重要な質問は次のとおりです。

1. 標準のドキュメント（チュートリアルを含む）をどのように変更しますか？ 現在の標準ライブラリHTTPAPIは、競合するプロトコル（FTPとHTTPなど）の詳細を排除することが望ましいアプローチと見なされていた時代にさかのぼります。 その後の10年半で、Web開発コミュニティは、リモートコマンド実行（SSHまたはWindows RCPのいずれかを使用）以外のほとんどのユースケースで、要求/応答スタイルのクライアント/サーバー相互作用への推奨アプローチとしてHTTPS + JSONに収束しました。リクエストAPIは、最新のPythonアプリケーション向けのそのモデルの事実上の標準クライアント実装です。
2. Requests APIをデファクトスタンダードからデジュリスタンダードにアップグレードして、すべてのCPython再配布チャネルに自動的に含まれ、CPython（および商用再ディストリビューター）の長期サポート保証に裏打ちされるようにしますか？すべての「標準ライブラリのみ」の教育活動？ （企業環境で使用するための基準には、CPythonが持つサポートとIP保証が含まれることが多いため、後者は依然として非常に一般的ですが、リクエストには含まれません。現在の状況では、多くのユーザーはリクエストをオプションと見なしません。使用の認定を受けるのは大変な作業です）
3. APIのようなリクエストを基に構築することで、標準ライブラリの他のどのモジュールを改善できますか？
4. APIのバージョンに依存しない実装としてリクエスト自体を変更せずに、代わりに、Guidoがayncio標準化作業にアプローチした方法と同様に、新しいリクエストに触発されたAPIを標準ライブラリに追加する方がよいでしょうか。

PSFで管理された開発作業のアイデアに関する限り、そのようなことを処理するための管理インフラストラクチャが整っていないため、私はそれに強く反対します。 PSFがこの分野でのクラウドファンディングの取り組みに貢献することを示唆する助成金の提案は別の話になります（レビューする特定の提案がなければ保証はありませんが、それは確かに私たちが議論しやすいアイデアです）。

一部のベンダーはすでにリクエストを再配布している場合がありますが、「リクエストのサポートも提供していますか？」 ベンダーまたはプラットフォームプロバイダーに尋ねなければならない別の質問になります。 したがって、長期的なリスク管理のコンテキスト（数週間や数か月ではなく、数年や数十年を考えてください）では、上流が退屈して他の何かに移った場合に、自己支援のリスクと責任を引き受ける必要があることを意味します。プラットフォームプロバイダーでの選択の程度の潜在的な減少を受け入れます。

標準ライブラリでは、通常、そのような懸念はありません。再配布業者が問題を解決することもありますが、商業的な状況では、上流で機能するものを破壊するベンダーは、問題のあるベンダーに問題を修正させるために非常に大きな力を発揮します。

ああ、標準ライブラリに実際に物を維持することを志願する前に答えるべきもう1つの重要な質問：世界の証券取引所の半分に電力を供給するのに役立つソフトウェアを出荷する責任を受け入れる準備ができていますか？これは企業インフラストラクチャで最も人気のある言語の1つです。科学プログラミングで最も人気のある言語（惑星間宇宙ミッションでの軌道計画に使用されることを含む）、Web開発で最も人気のある言語の1つ、教育機関の新しいコンピューターリテラシーイニシアチブで採用されている主要言語の1つは？

非常に低い信頼性レベル（多くの場合99％未満の稼働時間）が完全に受け入れられる重要でないサービスに取り組んでいる人々に、あなたの深刻な信頼の問題は不当であり、単に愚かな隠れた政治の問題であると不平を言う間、あなたはそれをする準備ができていますか？彼らは自分自身について気にすることはできませんか？

また、私が訂正したい誤った仮定：Pythonプログラマーの大多数は、リクエストはもちろん、pipについても聞いたことがない可能性があります。 これらは、Linuxリリースを長期的にサポートするシステムPythonでスクリプトを実行している人々です。ほとんどのオープンソース開発者は、アプローチを良いアイデアにするためにどのような状況が発生しているのかを考えるのをやめることなく、口に出せない軽蔑をすばやく表現します。

このコミュニティの採用サイクル時間は、本質的に年単位で測定されます。 現在、より速く進むことができるほど十分に厳密なCIを実行しているのは、業界のごく一部にすぎません。その部分のほとんどの人々は、既存の広い範囲を持つ人々の懸念に耳を傾けるのに十分な時間減速することに興味がありません。管理および近代化する必要のあるインフラストラクチャ。

テクノロジー採用曲線のキャズム後の部分は、「はい、このアプローチは十分に成熟しているため、標準ライブラリにプッシュして、真にユニバーサルにすることができます。予測"。

「オープンソースコミュニティ」フィルターバブルが私たちの見方を歪める可能性があることのより具体的な例として、ジェンキンスは企業のCI展開で70％以上の市場シェアを保持しています。

オープンソースに深く関わっている個人や組織にその視点を基づかせている場合は、「誰もが知っている」ことについての直感に頼る場合は、非常に慎重に行ってください。 ソフトウェア開発の大部分は依然として特定の組織のニーズを満たすためのカスタム作業であり、それを行う人々の大多数は依然としてオープンソースコミュニティではなく商用ベンダーからツールと情報を入手しています。

@dcramer
あなたが何について愚痴を言っているのかわからない。

この議論に非常に適切な言葉。 正当なカウンターがあなたの立場に作られるとき、あなたは女性を侮辱することを意図したスラーを使います。 しかし、コースのパー。 先に進む、

@ncoghlan

ポイント1：stdlibのリクエスト（リクエストも同様）を使用すると、ドキュメントが大幅に簡素化されると思います。 新しい言語を学ぶときに私が最初に行うことの1つは、HTTPの方法を理解することです。 それを特集することは、ガイドが関係なく恩恵を受けるものです。

ポイント2：APIとライブラリには、事実上のものとデジュリなものとの違いがあります。 APIは、標準ライブラリによって簡単に提供できます。 サポートについてのあなたの懸念は、含まれているリクエスト（コード）に向けられていると思います。

ポイント3と4について：それがここで議論されることかどうかはわかりません。 たぶん、python-ideasの方が良いでしょう。

PSFで管理された開発作業のアイデアに関する限り、そのようなことを処理するための管理インフラストラクチャが整っていないため、私はそれに強く反対します。

それは面白い。 確率だとは思いませんでしたが、http（lib）よりも良いものがあればいいのにと思います。

標準ライブラリでは、通常、そのような懸念はありません。再配布業者が問題を解決することもありますが、商業的な状況では、上流で機能するものを破壊するベンダーは、問題のあるベンダーに問題を修正させるために非常に大きな力を発揮します。

あなたが話しているレバレッジがわかりません。 私は、CPythonのDebianや他の再配布者によってensurepip、venv、その他のものが壊れているのを見てきました。 しかし、それはこの議論に正接しています。

ああ、標準ライブラリに実際に物を維持することを志願する前に答えるべきもう1つの重要な質問：世界の証券取引所の半分に電力を供給するのに役立つソフトウェアを出荷する責任を受け入れる準備ができていますか？これは企業インフラストラクチャで最も人気のある言語の1つです。科学プログラミングで最も人気のある言語（惑星間宇宙ミッションでの軌道計画に使用されることを含む）、Web開発で最も人気のある言語の1つ、教育機関の新しいコンピューターリテラシーイニシアチブで採用されている主要言語の1つは？

すでに述べたように、現在関与している人々のほとんどはプロジェクトを継続しません。 私はおそらく唯一の人ですが、アップストリームCPython開発での私の実績を考えると、既存の（および他の将来の）コア開発者にその負担を任せることは生産的ではありません。

テクノロジー採用曲線のキャズム後の部分は、「はい、このアプローチは十分に成熟しているため、標準ライブラリにプッシュして、真にユニバーサルにすることができます。予測"。

現実には、それらの人々は決して追いつくことはありませんね。 人々はまだPython2.4と2.5でソフトウェアを実行しています。 F5のロードバランサーはまだPython2.5のみをサポートしています。 2.7は、おそらく私の自然な生活の終わりまで使用されます（これはかなり長くなることを願っています）。 これらは本当にこの決定が最も強く影響する人々ですか？ あなたが説明する同じ人々がPython3に飛躍することは決してないかもしれません。そして現在、それはまだ_飛躍_です。 たぶん彼らがそれを検討することを決定した時までに、Python 3.8または3.9または4.2が出て、彼らにとってはるかに面倒ではなくなるでしょう。

そうです、私の主なポイントは、標準ライブラリを含める目的は、他のオープンソース開発者が使用するためのオープンソースライブラリを提供するというより一般的なタスクの目的とは_非常に_異なるということです。 リクエストチームが独立して維持されているライブラリのみを提供し続けることを選択し（私が非常に感謝しているコミュニティサービス、皆さんは素晴らしい仕事をしています！）、APIの標準化を後押ししない場合は、私たちは頼りになりますRHEL / Fedora / CentOS、Debian / Ubuntu、ActiveState、Enthought、Continuum Analyticsなどの再ディストリビューターでモジュールを取得して標準化することで_とにかく_、人々はそれが常に利用可能であると想定できるようになります（または少なくとも十分な頻度で適切な依存関係宣言が完全にパッケージ化されていない単一ファイルスクリプトのAPIに依存することに満足しています）。 ただし、ほとんどの入門ドキュメントは、標準ライブラリの方法でHTTPを実行するように人々を誘導する可能性が高いため、「HTTP for Python、2001年版」または「HTTPfor Python、2015年版」のどちらを習得するかは、 「標準ライブラリのみ」のソース、または推奨されるサードパーティモジュールを含むソース。

ただし、virtualenvとPEP 405、またはTwisted + Tornadoとasyncio、またはipaddrとipaddressの場合と同様に、標準ライブラリに_requests自体_を含めることは意味がないと思います。 むしろ、クロスバージョンの互換性コードや証明書のバンドルなどをすべて除外し、認証されたHTTPリクエストを処理するためのデフォルトのAPIとドキュメントを2015年まで提供するリクエスト_inspired_APIを含める方が理にかなっていると思います。標準。 それから2030年に、2030標準による_requests_ API設計がいかに古風であるかについて不平を言うでしょう（「HTTP？誰がそれをもう使用しますか？！？！」）、しかしそれは問題ありません、それはこれらのサイクルがどのように機能するかです（最初のAJAXまで）その後、JSONが登場し、XML-RPCが丘の王者でした）。 APIデザインが古くなっていると人々が不満を言う前に、APIデザインから5年が経過した場合、10は印象的で、15は本当に壮観です。

そのプロセスを開始するために必要な主なものは、標準化の取り組みを推進し、実装作業を行い、少なくとも最初の数年間のstdlibメンテナンスに取り組むことを目的として、RequestsAPIをどこでも利用できるようにするというアイデアに十分に動機付けられている人です。 別の方法は、インターネットから任意のコードをダウンロードして実行する意思がない、および/または実行できない開発者（厳格な規制デューデリジェンス要件を持つあらゆる業界のすべての人を含むカテゴリ）に到達するために、再配布者に大きく依存し続けることです。同様にリスクへの意欲が低い他の組織で働いている）。

他のいくつかの点に関しては、Debianでの現在のレバレッジは比較的弱いですが、上流の開発コミュニティとして私たちが設定した期待に比べて、有料の顧客が壊れていることについて直接不満を言うことができる商業的にサポートされている再配布では、レバレッジは優れています。

更新サイクルに関して、アップストリームの標準化（Python 3でも）が伝える重要なことの1つは、コミュニティのコンセンサスです。 その時点で、Python 3機能の「バックポート」であるライブラリは、Python 2とのバンドルを正当化するのがはるかに簡単になります。個人的には、まさにそのバンドルを実行するPython 2の相撲リリース（unittest2、subprocess32、enum34、contexlib2）を見たいと思います。 、トロリウスなど）、しかしそれ自体はまったく別の政治的戦いであり、特に2020年までそのような再配布者に依存しない相撲配布を維持するための関心とリソースが実際に利用可能であることを人々に説得するという点ではそうです。

@dcramerは私たちにあなたの時間を与えてくれてありがとう—それは本当に感謝しています：heart：

@ sigmavirus24すべてが順調です:)

stdlibインクルージョンのフロントに追加することはあまりありませんが、それ以外はありません。
いくつかのPEPやスレッドを調べたり、何をすべきかについて話し合ったりするのは良いことです。
Python stdlibで、そして多分昨年かそこらを振り返って
「この問題をどのように処理するか」という観点からの開発
これが標準ライブラリのモジュールである場合は異なります。」

これは事実上のスレッドになるかもしれないので、人々は彼らが言うときに見る
「stdlibにリクエストを追加することを検討する場合、何を追加/変更する必要がありますか」、
例外階層を更新するための別の叫び声をあげたいと思います。 私
通常、リクエストが失敗した場合、2つの質問があります-a）
影響？ およびb）リクエストを安全に再試行できますか？
DNSルックアップの失敗と壊れたパイプは、非常に異なる影響を及ぼします。
ただし、リクエストは現在、両方をConnectionErrorとしてグループ化します。 私はいくつかを詳しく説明しました
ここに含まれる作業の：
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

興味のある人ともっと話し合って幸せです。

ケビン・バーク
電話番号：925.271.7005 | 20milliseconds.com

20:15の日、2015年1月25日には、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.

誤解される可能性があります。 私には、それは標準ライブラリに対する蔑称的な態度のように聞こえます。標準ライブラリはもちろん、死んだライブラリで構成されていません。 このページにアクセスするまで、私はイライラし、リクエストの使用を控えました。これは興味深い議論であり、上記の表現よりもはるかに優れています。