所以 Python 3.14 昨天终于正式发布了。终于去除了 GIL（全局解释器锁），这使得多线程代码的运行速度大大提升，而不必处理多进程或其他繁琐的变通方法带来的脑力损失和开销。而且 uv 已经完全支持它，这真是令人印象深刻。 不过，我有点沮丧，因为我正在进行的主要项目有大量的库依赖，而新 Python 版本的主线支持总是需要很长时间，特别是当它们像 3.14 版本那样革命性和不同的时候。 所以我准备在不确定的未来忍受 GIL 地狱。 但后来我想，为什么不呢？让我看看 codex 和 GPT-5 能否克服这一切。所以我备份了我的设置，并让 codex 尝试，给它 uv 团队最近的博客文章作为起点。 有一些主要的障碍。我使用 PyTorch，它更新得 notoriously 慢。而且 pyarrow 也不支持 3.14。cvxpy 也是，作为凸优化库的包装器。 尽管如此，我还是想看看即使我们不得不处理“vendoring”一些库并从头开始用 C++、Rust 等构建一些东西，使用最新的夜间 GitHub 仓库而不是通常的 PyPi 库，我们能做些什么。 我告诉 codex 在网上搜索，阅读 GitHub 问题页面等，以便我们不必不必要地重新发明轮子（或者我应该说 WHL，🤣）。 为什么不呢？我可以随时测试，如果我无法让它工作，那我可以退回到 Python 3.13，不是吗？没有损失，没有伤害。 好吧，这花了很多小时的工作，几乎全部由 codex 完成，而我偶尔检查一下，但它成功让一切都运作起来了！ 当然，这需要很多次迭代，我还得调整一些东西以避免烦人的弃用警告（其中一些来自其他库，所以我最终不得不过滤它们）。 但这些库会随着时间的推移更新，以更好地支持 3.14，最终我将不再需要使用这些烦人的变通方法。 Codex 甚至建议将编译后的 whl 工件上传到 Cloudflare 的 R2（类似 s3），这样我们可以在不同机器之间轻松重用，并为我处理了所有细节。我自己绝对不会想到这一点。 每当出现另一个复杂或问题（例如，下面截图中显示的），codex 就会想出解决办法，毫不费力地克服一切。 如果你从未在 LLM 之前的“坏旧时代”尝试过这样的事情，那是一种无情的磨难，可能会耗费数天时间，然后遇到障碍，导致完全失败。 所以大多数时候尝试它都是太冒险的；你最好等 6 或 9 个月让事情变得简单一些。 无论如何，我仍然真的无法相信这一切都在运作！我们生活在未来。

当你意识到这条推文可能会表现良好时：