Python 3.15

发布页面与发行包的怪异之处

• 一些用户反馈 3.15 发布页面上的链接有损坏或锚点不正确的问题（例如 Sentinel、lazy imports 链接到了页面底部）。
• xz 源代码压缩包明显比 3.14 更大；调查显示原因大约是文档里约 10MB 的动画 GIF（用于 Tachyon 性能分析器）。
  • 有些人认为这是不必要的臃肿，更希望使用轻量级的、基于 SVG 的文档。
  • 也有人认为批评者应该自己贡献更好的素材。

---

性能、JIT 与性能分析

• 实验性 JIT 报告的 7–12% 速度提升（取决于平台）受到欢迎，被视为扎实的渐进式收益。
• 新的 Tachyon 采样性能分析器被强调为尤其适合在生产环境中分析运行中的进程。

---

Lazy imports 与启动速度

• PEP 810 的显式 lazy imports 引发了兴奋，尤其适用于大型或对启动时间敏感的应用。
• 有人问为什么不全局启用；回答指出：
  • 导入时副作用（例如注册表）以及非确定性的导入顺序。
  • PEP 810 明确记录了这些权衡。
• 文中提到一个静态分析器（“lifeguard”），它会扫描代码以识别哪些地方可以安全启用 lazy imports。

---

版本支持、打包与系统自带 Python

• 维护者欢迎 3.15，主要因为 3.10 现在已经 EOL，这让他们可以依赖 3.11+ 特性。
• 争论点：
  • 维护者认为无限期支持旧版本不现实；用户可以停留在旧包版本上，而元数据会确保 pip 选择兼容的发行版。
  • 一些用户不喜欢“放弃”旧 Python 成为常态，尤其当它们仍被发行版或厂商随系统一起提供时。
• 企业/Linux 发行版往往会在上游 Python 支持结束后继续存在，但会在并行分支中提供更新的解释器。
• macOS 上固定/捆绑的 Python（通过 Xcode 提供的 3.9）被视为过时且令人困惑；共识是避免使用系统 Python，而应使用受管理的环境（例如 uv、virtualenvs）。

---

类型标注、AI 与性能

• 一位评论者声称 LLM 在未标注类型的 Python 上表现更好，而且由于大多数训练数据都没有类型标注，注解可能只是“噪音”。
• 其他人反驳说：
  • 目前运行时性能并不会因为注解而受益。
  • 类型对于人的可读性、正确性以及专业级代码仍然至关重要。

---

无 GIL Python 与 abi3t

• 新的、面向无 GIL 构建的“abi3t”稳定 ABI 被称赞为生态系统的重要推动因素。
  • 例如：一些关键库已经发布了单一 wheel，可同时用于 3.15+ 的 GIL 构建和无 GIL 构建。
• 维护者指出，使用稳定 ABI 后 CI 开销大幅减少，并预计未来跨版本支持会更容易。
• 对哪些 C API 会升级进入 limited/abi3(t) 接口范围，仍然存在持续讨论。

---

语言特性与 PEP

• 几个虽小但长期被期待的特性获得了积极关注：
  • 推导式中的解包（PEP 798）。
  • 内置 frozendict（PEP 814）。
  • 跨平台默认使用 UTF-8 编码（PEP 686），尤其有利于 Windows 和配置错误的容器。
• 一些用户对 UTF-8 竟然之前不是统一默认值感到惊讶，这反映出此前行为其实相当微妙（依赖 locale）。

---

语言生态与 Rust 之争

• 一个侧线讨论猜测只有 TypeScript/JavaScript、Rust 和 Python 会“存活”下来，并且会有大规模重写为 Rust 的情况（包括一些真实世界的例子）。
• 其他人对此提出反对：
  • 指出现有生态（C、C++、Java、C#、Swift、Kotlin、COBOL、嵌入式 C）不太可能消失。
  • 指出 CPython 的核心并没有被重写为 Rust；当前工作只是探索允许某些 Rust 组件。
• 有人认为更少的语言会更好；也有人更偏好持续的多样性和创新，尤其是在 AI 工具的加持下。