Python Language Summit 2026 的闪电演讲把几个看似分散、实际彼此关联的话题放到了一起：是否值得承受一次性的 ABI 破坏，如何让程序中断更安全，怎样用 EktuPy 降低 Python 学习门槛，以及 CPython 是否应该用 AGENTS.md 帮助编码代理理解仓库规则。演讲还特别呼吁开发者亲自阅读 PEP 836，而不是只看二手结论。
这些议题共同指向一个问题：Python 在继续演进时，怎样同时照顾底层生态、运行时可靠性、初学者体验和新的开发工具？
一次 ABI 破坏，换来的不能只是“代码更整洁”
ABI（应用二进制接口）决定了已经编译的扩展模块如何与 Python 运行时交互。与普通 Python API 变更不同，ABI 变化可能让现有的 .so、.pyd 或二进制 wheel 无法继续加载，即使扩展源码一行都没改。
因此，“一次性 ABI break”不只是 CPython 内部实现问题。它会沿着依赖链传递给：
- NumPy、数据库驱动、加密库等原生扩展；
- wheel 构建和发布流水线；
- Linux 发行版与企业内部软件仓库；
- 无法现场编译扩展的最终用户环境。
判断这种变更是否值得，不能只看核心代码能简化多少。更重要的问题包括：它是否消除长期技术债务，是否为未来优化打开空间，生态能否提前获得测试版本，以及包维护者是否有清晰的迁移窗口。
维护含原生扩展的项目时，可以先用下面的命令检查当前解释器和已安装 wheel 的兼容标签：
python -VV
python -c "import sysconfig; print(sysconfig.get_config_var('SOABI'))"
python -m pip debug --verbose
其中 SOABI 可以帮助定位解释器使用的扩展模块 ABI 标识；pip debug 输出的兼容标签则说明当前环境能够安装哪些 wheel。它们不能自动判断未来变更是否兼容，但适合加入预发布版本测试和故障报告中。
“安全中断”意味着先进入一致状态，再退出
用户按下 Ctrl+C 看似只是停止程序，但中断可能发生在写文件、提交事务或更新多个内存对象的中间。如果程序立即退出，就可能留下半写入文件、未释放资源或业务状态不一致的问题。
在现有 Python 中，可以把信号处理器设计得尽量轻量：处理器只设置停止标记，主循环在明确的安全点完成清理。下面的示例可直接运行，然后按 Ctrl+C 观察退出过程：
import signal
import threading
import time
stop_requested = threading.Event()
def request_stop(signum, frame):
print("\n收到中断请求，将在当前任务完成后退出……")
stop_requested.set()
signal.signal(signal.SIGINT, request_stop)
try:
task_id = 0
while not stop_requested.is_set():
task_id += 1
print(f"开始任务 {task_id}")
# 模拟一个不应在中间留下半成品的工作单元
for _ in range(4):
time.sleep(0.25)
print(f"任务 {task_id} 已提交")
finally:
print("释放连接、刷新缓冲区并保存检查点")
实际服务还应为清理过程设置超时，并区分“停止接收新任务”和“立刻终止”。需要注意，Python 信号处理器通常在主线程执行；不同操作系统对 SIGTERM 等信号的支持也不完全一致。异步服务则可以把同一思路映射为 asyncio.Event 和生命周期钩子。
从 EktuPy 到 AGENTS.md：同时服务学习者和编码代理
EktuPy 被概括为“Scratch，但使用 Python”。这个方向的价值不只是把积木换成代码，而是尝试保留即时反馈和低风险试错，同时让学习者接触真实的 Python 语法。对教学工具而言，关键边界是避免形成只能在专用环境中运行的“类 Python 方言”；如果学习成果可以逐步迁移到普通 .py 文件、测试和包管理工具，过渡成本会更低。
另一场闪电演讲提出为 CPython 准备 AGENTS.md。这类文件可以向编码代理明确仓库布局、构建方式、测试命令和禁止事项，减少代理根据通用经验猜测项目规则的情况。
来源摘要没有给出 CPython 文件的正式内容。若自己的项目想实践这种约定，可以从下面这个最小版本开始，再按仓库实际情况修改：
# AGENTS.md
## Scope
These instructions apply to the entire repository.
## Setup
- Create a virtual environment with: python -m venv .venv
- Install development dependencies with: python -m pip install -e ".[dev]"
## Validation
- Run unit tests with: python -m pytest
- Run formatting checks with: python -m ruff check .
## Change rules
- Do not modify generated files by hand.
- Add a regression test for every bug fix.
- Keep public API changes backward compatible unless the issue explicitly approves a break.
AGENTS.md 不应成为另一份无人维护的 README。更稳妥的做法是只记录可执行、可验证的约束，并确保其中的命令在 CI 中也会运行。它可以帮助代理，但不能代替代码审查、权限隔离和对生成补丁的测试。
PEP 836 应该怎样读
闪电演讲明确呼吁阅读 PEP 836，但摘要没有提供该 PEP 的技术结论，因此不宜凭标题或转述推断其内容。可以直接打开正式文本：
python -m webbrowser "https://peps.python.org/pep-0836/"
阅读时建议依次检查状态、目标 Python 版本、动机、规范、向后兼容性、安全影响和被拒绝的替代方案。尤其要区分“已接受的语言行为”“仍在讨论的提案”和“供生态试验的方向”，避免把 PEP 编号当成已经落地的功能承诺。
团队现在可以做什么
这些闪电演讲并不要求团队立即迁移，而是提供了几项可以提前完成的准备工作：
- 维护原生扩展时，持续测试 Python 预发布版本并保留 ABI 诊断信息；
- 为命令行工具、工作进程和服务定义清晰的安全停止点；
- 评估教学工具时，检查学习成果能否迁移到标准 Python 工具链；
- 引入
AGENTS.md时，只写真实可执行的仓库规则，并让 CI 验证关键命令； - 对 PEP 直接阅读正式文本，确认状态和兼容性章节后再做技术决策。
ABI、信号处理、编程教育和编码代理看起来分属不同层面，但它们都在处理同一种成本：变化如何被生态可靠地吸收。越早把兼容性、退出语义和贡献规则变成可测试的约束，升级时就越少依赖临场判断。