同じく！君のコメントのおかげでやっと気づいたよ。

あと、htmlxとhtmxも混同してるのかな？

あ、htmxのことを言ってるんだね。私も同じだよ。しばらくその記事を読んでたけど、「HTTPXはPython用の非常に人気のあるHTTPクライアントです。」って言葉に混乱して、「なんでOpenAIはhtmxを使ってるの？」って思ってたけど、最終的に何が起こってるのか気づいたよ。

私もこの記事をずっと間違って読んでたわ。

確認済み、機能も増えて、切り替えも楽だよ。

httpxの基盤はあんまり良くないと思う。最初にPythonのrequestsをasyncに対応させた「ポート」だから成功したんだろうけど、それ以外はイマイチ。APIもパフォーマンスも微妙だし、調整も大変。メンテナの考え方もあんまり良くない。最後のポイントについては、記事でいくつか言及されてたけど、理由もなく突然プロダクションプロジェクトが壊れることもあるからね。完璧じゃないけど、みんなAiohttpに切り替えることをおすすめするよ。

確かにniquestsがもっと使われてないのは残念だよね。フランス語の(c'est Français)の議論を使おうとしたら、初期のユーザーをたくさん集められると思うよ。

それって「knee-quests」それとも「nigh-quests」？最近、こういう絵文字付きのコミットをよく見るようになったけど、変わってるね。

ありがとう、君のプロジェクトにリンクするね。

半端なサイドプロジェクトはPyPIを汚すだけだから、思い切ってフォークを作ってそのトレードオフを受け入れた方が、長期的には楽だよ。

まだTrioのサポートはないよね？少なくとも僕にとっては、httpxを使う主な理由だし、数年前に「import httpx」って打った時からずっとそうだよ。（それに、READMEのスポンサーシップのことがなんか怪しい感じがする。もしかしたら、僕があまりにも痛い目にあったからかも—一般的にサポートを売ることを否定するつもりはないけど。）

うちの会社ではniquestsに切り替えたんだけど、はい、httpxより10倍いいって言えるよ :)

あ、関わってる人の一人をすぐに認識したよ、ドラマ好きな人だね。でも、mkdocsパッケージをハイジャックするのは間違ったやり方だと思う。FOSSの世界はフォーク恐怖症になりすぎてるよ。mkdocsをフォークして、自分の好きなように進めればいいのに。

Read the DocsがMkDocsから利益を得て、何も返さないことを批判するスレッド。 > ソースコードを開放しないのはオープンソースソフトウェア開発の原則に反するって指摘もあるね。こういう感情を持ってる人がBSDライセンス（このプロジェクト）を選ぶのを見ると、いつも面白いと思う。もしそういう行動を抑制する文化が欲しいなら、どうしてそれを明示的に許可するライセンスを選ぶの？強制できるかどうかに関わらず、そのライセンスは基本的に、あなたが持ちたいコミュニティのタイプを示すCoCの一種だよ。

もしこれがテレビ番組だったら、たぶん見ると思うけど、なんてドラマなんだ。

一方で、そのプロジェクト乗っ取りの話はJia Tanっぽい匂いがする。もう一方では、MkDocsの作者が言ってる性別に関する不満のコメントがめちゃくちゃで、彼らが作ったものには絶対触れたくないな。

これは単なるオープンソースじゃなくて、HTTPリクエストにおけるXKCD 2347的な基盤的役割を持つ巨大なパッケージエコシステムに参加することだよ。サイドプロジェクトを個人のホームページに載せて放置するのはいいけど、中央インフラにするなら、参加者に応じたり、拡張したり、メンテナンス権を譲ったりしないとね。

さっき見たときは45だったのに、今は261になってる。

そしたら壊れてることが分かったんだ。修正を提案したけど、無視されて、それ以来2024年11月からリリースもない。これってフォークする理由としてはかなりいいと思う。 > HTTPリクエストを送るのは現代では基本的な機能だし、標準ライブラリには使いやすくて、機能満載で、実績のある非同期対応のクライアントが含まれるべきだよね。でもPythonにはないし、JavaScript（まあNodeも）、Golang（http/netはurllibよりもひどいと思う）、Rust、Java（UrlRequestはPythonと同じ）、それに.NETのHttpClientも…まあまあって感じ。正直、リクエストが標準化されて標準ライブラリに組み込まれてないのはいつも驚きだわ。

HTTPリクエストを送るのが基本的な機能だと思うかもしれないけど、いろんな言語でやってみると面白いよ。ずっと前（2020年、見方によってはそんなに昔じゃないけど）、依存関係なしでNodeでHTTPリクエストをするのがちょっと面倒だなって驚いたことがある。以下のコードみたいにね：const response = await new Promise( (resolve, reject) => { const req = https.request(url, { }, res => { let body = ""; res.on("data", data => { body += data; }); res.on('end', () => { resolve(body); }); }); req.end(); });

HTTPクライアントは「必要なソフトウェアのビルディングブロック」と「RFC 2616の実装が難しい細かい部分」の交差点にある。実際、Pythonとはあまり関係ないよ。

みんな「フレンドリー」と「フル機能」をどう定義するかは違うからね。悪いソフトウェアを神格化しないためにも、標準ライブラリはできるだけミニマルに保った方がいいと思う。プログラミング言語には、その時々の一般的に使われる「ベストプラクティス」のライブラリを含む「標準ディストリビューション」を用意することもできるかもしれない。

これはPython特有の問題じゃなくて、人間特有の問題だよ。Pythonが人気だから、Pythonパッケージでより頻繁に、より公に起こるだけなんだ。

ブラムの法則: Pythonはすべてを簡単にしてくれるね。

「HTTPリクエストを送るのは現代の基本的な能力で、標準ライブラリには使いやすくて、機能が充実していて、テスト済みの非同期クライアントが含まれるべきだ。」多くの言語が標準ライブラリでHTTPに苦労しているのを見てきたけど、他の部分が素晴らしくてもそうなんだよね。「使いやすさ」と「すべてのユースケースをカバーすること」のバランスを取るのが難しいと思う。ほとんどの言語は後者に偏りがちだけど、それも理解できる。

Pythonのメンテナーたちは、昔の「バッテリー付き」アプローチの影響でまだ焼けた感じが残ってるんじゃないかな。

私の見たところ、良い標準HTTPライブラリがないのは人気のある言語では普通みたい。Python、Ruby、Rustなど、どれもパッとしない標準ライブラリか、そもそもライブラリがないかだと思う。多くの言語は、必要なRFCや暗黙のRFCがたくさんあって、リクエストを作るための異なるイディオムもたくさんあって、何をサポートするかの線引きも難しいから、決定圧力が多すぎるんだよね。例外的なのはGoで、素晴らしいライブラリがあるけど、Goは全体的に素晴らしい標準ライブラリを持ってることで有名だよね。

httpxは非同期サポートがあるけど（aiohttpみたいに）、urllibはブロッキング専用なんだ。N個の同時リクエストが必要な場合、urllibはNスレッドかプロセスが必要になるよ。

標準ライブラリに非同期HTTPクライアントがあれば、pipのようなツールにも良い影響があるだろうね。もっと非同期の処理をすることで、uvがずっと速くなる理由の一つでもあるんだ。

modshimはお金のパッチを当てるわけじゃなくて、パッケージの外部APIをラップしているだけみたいだけど、もし変更がパッケージの内部に深く入っているなら、ほとんどのパッケージを外から再実装することにならない？