それで、昨日、Python 3.14がついに実際にリリースされました。最後に、GIL(グローバルインタープリターロック)を削除し、マルチプロセッシングやその他のハッキーな回避策の脳の損傷やオーバーヘッドをすべて処理することなく、はるかに高速なマルチスレッドコードを可能にします。そして、uv はすでにそれを完全にサポートしており、これは非常に印象的です。 しかし、とにかく、私が取り組んでいるメインプロジェクトには膨大な数のライブラリ依存関係があり、特にバージョン3.14のように革新的で異なる場合、新しいPythonバージョンのメインラインサポートを得るのには常に非常に長い時間がかかるため、私は少しがっかりしました。 だから私は無期限の将来、ギル地獄に耐えることを諦めました。 しかし、なぜそうしないのかと思いました。コーデックスとGPT-5がすべてを乗り越えることができるかどうか見てみましょう。そこで、設定をバックアップし、コーデックスに試してみてもらい、UV チームからの最近のブログ投稿を提供して開始しました。 いくつかの大きな障害がありました。私はPyTorchを使用していますが、これは更新が遅いことで有名です。また、3.14 をサポートしていなかった pyarrow もあります。凸最適化ライブラリのラッパーであるcvxpyと同じです。 それでも、通常のPyPiライブラリの代わりに、最新の夜間のGitHubリポジトリを使用して、いくつかのライブラリを「ベンダー化」し、C++やRustなどでいくつかのものをゼロから構築するという脳の損傷に対処しなければならないとしても、何ができるかを見たかったのです。 私はコーデックスに、ウェブを検索したり、GitHubの問題ページを読んだりするように指示し、不必要に車輪(またはWHLと言う🤣べき)を再発明しないようにしました。 なぜ駄目なのですか。私はいつでも物事をテストすることができ、それを機能させることができない場合は、Python 3.13に戻ることができますよね?害も反則もありません。 まあ、何時間もかかり、ほとんどすべてがコーデックスによって行われ、時々確認しましたが、すべてが機能することができました。 確かに、それはたくさんの反復を要し、迷惑な非推奨の警告を避けるためにいくつかのものを微調整しなければなりませんでした(その一部は他のライブラリからのものなので、最終的にはそれらをフィルタリングする必要がありました)。 しかし、これらのライブラリは時間の経過とともに更新され、3.14をより適切にサポートし、最終的にはこれらの迷惑な回避策を使用する必要がなくなります。 Codex は、コンパイルされた whl アーティファクトを Cloudflare の R2 (s3 など) にアップロードして、マシン間で簡単に再利用できるようにすることも提案し、すべての詳細を私に代行してくれました。自分だけではそんなことをしようとは思わなかった。 別の複雑さや問題が発生するたびに (たとえば、下のスクリーンショットに示されているもの)、コーデックスはそれを理解し、何もないようにすべてを耕しました。 LLM 以前の「悪い時代」にこのようなことをしようとしたことがないなら、それは何日も費やされ、その後障害にぶつかり、完全に全滅する可能性があるありがたい苦労でした。 そのため、ほとんどの場合、試すことさえできないほど危険でした。物事が再びシンプルになるまで6、9か月待ったほうがいいでしょう。 とにかく、すべてがうまくいっていることが今でも信じられません。私たちは未来を生きています。

ツイートがおそらくうまくいくだろうと気づいたら: