Python PEP 697 摘要 PEP 697 提议为 Limited C API 增加对"不可见类型"扩展的支持，允许通过负值 basicsize 方式在父类基础上安全添加子类专有数据区。核心内容包括： 新增机制允许子类完全不依赖父类内存布局，通过负 basicsize 指定额外空间，用 PyObject_GetTypeData 获取该区域 特别处理可变尺寸对象，新增 Py_TPFLAGS_ITEMS_AT_END 标志表示可变数据在对象末尾，确保安全继承 引入相对偏移量概念，用

PEP 696 为 Python 类型系统引入了类型参数默认值的概念，允许 TypeVar、ParamSpec 和 TypeVarTuple 指定默认类型。当未显式提供类型参数时，将自动使用默认类型。该提案借鉴了 C++、TypeScript 和 Rust 等语言的类似特性，并通过示例展示了在常见场景（如泛型类、Generator 类型）中的实用价值。规范详细说明了默认值的使用规则，包括顺序约束、参数间引用、边界条件等，同时明确了与 bound/constraint 的交互规则。该特性将简化泛型代码的类型注

PEP 695 为 Python 引入改进的类型参数语法，主要特点包括：1）在类/函数/类型别名声明中直接使用方括号定义类型参数；2）新增 type 语句声明类型别名；3）简化类型参数约束语法（支持 T: str 和 T: (str, bytes) 形式）；4）消除对 Generic 基类和 TypeVar 导入的依赖；5）明确了类型参数作用域规则。新语法使泛型编程更直观，解决了旧语法中类型变量作用域混淆、变协性理解困难等问题，同时保持了与现有类型系统的兼容性。运行时通过 TypeAliasType 表示类

摘要 PEP 692 提出使用 TypedDict 配合 Unpack 类型来精确标注 Python 函数的 **kwargs 参数类型，解决当前仅能标注单一类型的问题。该方案允许为不同关键字参数指定不同类型，同时保持类型检查器的严格性。通过引入 Unpack[TypedDict] 语法，函数可以明确声明每个关键字参数的名称和对应类型，包括必需和可选参数。该特性有助于旧代码迁移至类型检查环境，特别适用于需要传递多类型关键字参数的场景。参考实现已在 mypy 和 pyright 中提供。

PEP 689 为 Python C API 引入了一个新的"不稳定层级"(Unstable C API Tier)，位于现有公开API和内部API之间。该层级API以PyUnstable_为前缀，保证在补丁版本中稳定，但允许在小版本间变更。同时明确规定下划线前缀仅用于私有API。初始迁移包括代码对象构造器等API，未来将逐步扩展。该提案旨在为需要访问CPython内部机制的工具提供更清晰的API稳定性指引，同时减少不必要的代码破坏。兼容性方面，重命名API将保留旧名直至实际不兼容变更发

PEP 688 提议在Python层提供buffer协议的可访问API，目前该协议仅能在C代码中使用。新提案将引入两个特殊方法__buffer__和__release_buffer__，允许Python类实现buffer协议，同时添加collections.abc.Buffer抽象基类用于类型注解和运行时检查。这将解决当前类型系统无法识别buffer协议的问题，并为纯Python实现的buffer类提供支持。该提案还包含错误处理机制和兼容性考虑，同时取消类型注解中bytes作为buffer类型的特殊含义。实

摘要 PEP 758 提议简化 Python 异常处理语法，允许在未使用 as 子句时省略 except 和 except* 块中的括号。当前捕获多个异常时要求加括号（如 except (A,B)），新语法将允许直接写为 except A,B。这一改动旨在提升代码简洁性和可读性，同时保持与现有语法的完全兼容。当使用 as 捕获异常实例时，仍要求保留括号以避免歧义。该 PEP 不改变异常处理语义，仅优化语法形式，使 Python 的异常处理语法与其他逗号分隔列表的语法更加一致。

摘要：PEP 779 为Python实现无GIL的自由线程（free-threaded）构建制定了从实验阶段进入"正式支持"阶段的标准。该提案基于PEP 703（使GIL可选）的三阶段计划，要求free-threaded构建达到：性能损失≤15%、内存占用增加≤20%、API稳定且文档完善。当前Python 3.13已实现10%性能损失和15-20%内存增加的实验性版本，预计3.14可能满足正式支持条件。该阶段将帮助评估生态兼容性，为后续是否成为默认构建提供决策依据，但明确第三阶段需单独

摘要 PEP 698 提议为Python类型系统新增@override装饰器，用于显式标记子类覆盖父类的方法。该特性可帮助类型检查器在基类重构时检测潜在问题，防止因方法名变更或删除导致的子类覆盖失效。该装饰器遵循与@final相似的运行时行为，支持方法、属性、静态方法等多种场景，同时允许项目选择是否强制要求所有覆盖必须显式声明。这一特性借鉴了C++、Java等多语言的实践，能显著提升代码重构安全性，特别是对于大型项目和多模块协作场景。

摘要 PEP 768 提案为 CPython 引入安全的外部调试接口，使调试器能够安全附加到运行中的 Python 进程而无需重启。该方案通过在 PyThreadState 中新增调试控制结构，利用解释器现有的求值循环机制，确保调试代码仅在明确定义的安全点执行，避免传统代码注入方式可能导致的内存冲突和解释器崩溃问题。该接口实现零运行时开销，支持类似 gdb 的进程附加调试功能，为生产环境调试提供了可靠解决方案，同时为未来与可观测性工具集成奠定了基础。

Python PEP 765 提议禁止在 finally 块中使用 return/break/continue 语句，以解决该特性导致的常见错误和异常被意外吞没的问题。实证分析显示，这种用法在主流代码中极为罕见（每百万行仅2-4次），且多数情况下存在潜在错误。PEP 建议首先在Python 3.14中发出SyntaxWarning，未来可能升级为SyntaxError。该提案基于PEP 601被否决后收集的新数据，并借鉴了PEP 654中类似限制的经验。维护者调查表明，大多数代码所有者愿意且能够轻松修复相关

摘要：PEP 775 提议将 zlib 压缩库设为构建 CPython 的必需项，仅对 WASI 平台例外。该提案认为主流 CPython 构建已普遍依赖 zlib（如 pip 等工具），无 zlib 构建实际处于"不支持"状态。规范要求移除相关兼容性代码，使缺失 zlib 时直接抛出 ImportError。PEP 后被作者撤回，主要因社区对 WASI 例外的反对以及提案价值有限。撤回前已通过 PR 实现配置警告、测试调整等变更，并保留未来彻底强制要求 zlib 的可能性。（149字）

摘要 PEP 667 旨在解决 Python 中函数命名空间实现不一致的问题。早期版本中，所有命名空间都通过字典实现，但后来出于性能考虑，函数命名空间的实现发生了变化，导致通过 locals() 和 frame.f_locals 访问时出现不一致行为，并产生了一些线程和协程相关的 bug。 该提案主要改进点包括： frame.f_locals 将作为写穿代理，确保修改能立即反映到底层变量 locals() 在函数作用域下返回独立快照而非共享字典 统一模块、类和函数作用域下的行为 修复了通过 frame 对象

此外，如果实现足够隔离，则可以真正实现多核并行，每个解释器不再共享 GIL。将新增 PyModuleDef 槽位声明是否兼容解释器级 GIL，初期需显式 opt-in，后续可改为默认 opt-in，支持 opt-out。per-interpreter GIL 尚未深入评估，但只要解释器隔离充分，不会让 CPython 变慢，且可解锁多核并行。包括初始化/终结清理，扩展隔离机制，内建/标准库扩展隔离，增加 _PyRuntimeState，静态分配常用对象等。部分全局对象在解释器间共享，但仅限于永生对象。

Python PEP 649 提出了一种新的注解延迟求值机制，通过引入__annotate__描述符属性解决传统注解的前向引用和循环引用问题。该方案将注解表达式求值延迟到首次访问时，支持三种格式返回：原始值、前向引用代理或源码字符串。相比PEP 563的字符串化方案，新机制既保留了静态类型检查的优势，又满足了运行时注解用户的需求。该提案若通过，将取代PEP 563并逐步弃用其行为，同时保持对现有代码的兼容性。

任一事件启用/禁用会影响组内所有事件。禁用 CALL 不会影响已发生的 C_RAISE/C_RETURN，但会影响后续事件。利用 quickening，预计在 3.12 下开启调试器的代码，性能将好于 3.11 下未开启调试器的代码。事件集变化时，VM 会立刻更新所有线程调用栈上的代码对象，并设置陷阱，确保后续调用的代码对象被正确插装。需注意分析器本身的插装开销会影响结果，除非确需精确调用计数，建议用统计分析器。无事件激活时，本 PEP 应带来 1~2% 的性能提升（少了 settrace 的支持）。

PEP 399要求CPython标准库中同时有C和Python实现的模块必须保持兼容性。该提案规定：1) C加速模块必须通过纯Python实现的测试套件；2) 新模块加入标准库需提供纯Python实现（除非特殊豁免）；3) 加速代码不得暴露额外API。此举旨在确保不同Python虚拟机（如PyPy、Jython）能复用标准库代码，减少重复开发。测试应同时覆盖两种实现以验证语义一致性，C代码应优先使用抽象API操作对象。该提案自Python 3.3起生效，但不强制要求已有模块补充纯Python实现。

摘要 PEP 554提议在Python标准库中新增interpreters模块，以公开CPython长期存在但仅限于C-API的多解释器(subinterpreters)功能。该提案旨在： 提供基础的多解释器管理接口，包括创建、销毁解释器和跨解释器通信能力 通过解释器隔离特性支持新的并发模型(如CSP) 配合PEP 684的解释器级GIL实现更好的并行计算 核心内容包括： interpreters模块API，支持解释器创建、状态管理和简单数据共享 新增InterpreterPoolExecutor执行器 提

PEP 399 规定了标准库中纯 Python 和 C 加速模块的兼容性要求：新增模块必须有纯 Python 实现（特殊情况可豁免），C 加速代码必须通过相同的测试套件以保证语义一致性。该要求旨在减少不同 Python 实现间的重复开发，确保模块在所有 VM（如 PyPy、Jython）中可用。C 加速模块不得暴露额外 API，必须优先使用抽象对象操作。已有模块虽不强制修改，但鼓励补充纯 Python 实现，测试代码需同时覆盖两种实现版本。该提案从 Python 3.3 开始执行。

Python PEP 554 提案旨在将CPython长期存在的多解释器(subinterpreters)功能从C-API引入标准库，新增interpreters模块和InterpreterPoolExecutor执行器。该功能允许在同一进程内运行多个相对隔离的解释器，为并发编程提供新范式，特别是配合PEP 684引入的解释器级GIL后更具价值。提案包含解释器创建管理、基础通信机制（通过__main__命名空间共享数据和使用通道）等功能，同时为扩展模块维护者提供兼容性指导。虽然存在争议，但该提案通过暴露底层

摘要：PEP 784 提议将 Zstandard（Zstd）压缩算法添加到 Python 标准库，作为现代高性能压缩的事实标准。该提案计划将 Zstd 实现为 compression.zstd 模块，并重构现有压缩模块到 compression.* 命名空间下以避免命名冲突。Zstd 相比现有算法具有显著性能优势，已被广泛采用（如 ZFS、Btrfs 文件系统），并支持 IETF 标准化（RFC 8478）。实现基于 pyzstd 项目，最低支持 Zstd v1.4.5。该方案不影响向后兼容性，同时为未来压

摘要 PEP 775 提议将 zlib 设为构建 CPython 的必要组件，仅保留 WASI 平台作为例外。该提案认为 zlib 已成为事实标准，应明确其必需性，简化代码并统一行为（缺失时直接抛出 ImportError）。虽然允许非官方无 zlib 构建，但会标记为"不支持"。该 PEP 后因社区反对（特别是 WASI 例外争议）于 2025 年被撤回。提案还涉及修改相关模块（shutil/tarfile等）的错误处理机制，并调整 PEP 11 的兼容性声明。

PEP 782 提出新增 PyBytesWriter C API，用于高效创建不可变的 bytes 对象。该提案软弃用了 PyBytes_FromStringAndSize(NULL, size) 和 _PyBytes_Resize() 方法，因为这些方法将不可变对象当作可变对象处理。新 API 提供了更高效的缓冲区分配策略，支持自动扩容并减少内存拷贝。主要功能包括：创建写入器、写入数据、格式化输出、调整大小等操作，最后通过 Finish 方法生成最终的 bytes 对象。该 API 不是线程安全的，但能避

Python 的 tarfile 模块新增 extractall 过滤器功能，通过 PEP 706 引入安全改进。该提案针对 tar 归档解压时的安全隐患（如符号链接攻击），新增 filter 参数允许用户控制文件提取行为。提供三种内置过滤器：完全信任、类 UNIX 模式和数据安全模式。经过弃用期后，最严格的数据安全模式将成为默认选项。该方案还新增 TarInfo.replace() 方法便于修改元数据，并建议未来其他归档库（如 zipfile）采用类似 API。这一改进旨在解决长期存在的安全问题（如 CV

PEP 742 提案新增 TypeIs 类型守卫，改善 Python 类型系统中用户自定义类型缩小功能。与现有 TypeGuard 不同，TypeIs 能够在条件判断的 if 和 else 分支同时缩小类型，行为更接近 isinstance()。该提案解决了众多开发者反馈的问题，如标准库中 inspect.isawaitable() 等函数的类型检查不准确问题。TypeIs 通过计算参数类型与返回类型的交集和补集来精确缩小类型范围，同时保持与现有类型系统的兼容性。文档将优先推荐使用 TypeIs，而 Typ

摘要 PEP 721规范了Python源码分发包(sdist)的安全解包标准，要求使用tarfile.data_filter过滤器处理tar归档文件。该PEP明确了在不支持过滤器的旧版Python上的处理方式，并规定了工具应遵循的最低安全标准，包括禁止危险文件类型、处理权限位等。主要目的是统一各工具的解包行为，提高安全性同时保持向后兼容性。该标准针对打包工具开发者，不影响普通用户操作。

Python PEP 737 摘要：统一类型名称格式化 该PEP提案旨在为Python C API引入统一的类型名称格式化方式，解决当前C和Python实现间类型名显示不一致的问题。主要变更包括： 新增PyType_GetFullyQualifiedName()和PyType_GetModuleName()函数，用于获取类型的完全限定名和模块名 在PyUnicode_FromFormat()中添加%T、%#T、%N和%#N格式说明符 建议新C代码使用完全限定名而非截断的类型名 此提案解决了C代码中直接使用t

Python PEP 730：为iOS添加官方支持 本PEP提议在CPython中正式添加iOS作为支持平台，目标是在Python 3.13实现Tier 3支持。iOS作为主流移动平台，过去10年已有BeeWare和Kivy等项目成功实现非官方支持。技术层面，iOS使用Darwin内核但存在平台差异，支持两种ABI（iphoneos和iphonesimulator）及多种CPU架构。由于iOS特殊限制： 禁止多进程操作 动态库必须以Framework形式打包 不支持传统控制台交互 限制代码下载 规范包括平台

Python模板字符串提案摘要 PEP 750提出在Python中引入模板字符串(t字符串)，作为f字符串的扩展。模板字符串使用t前缀，生成Template类型而非直接生成字符串。该提案允许开发者拦截和处理字符串插值，解决了f字符串在SQL拼接、HTML生成等场景的安全限制。模板字符串保留PEP 701的全部语法特性，支持调试说明符，并通过Template和Interpolation类提供对字符串各部分的细粒度访问。该特性可应用于安全检查、网页模板等领域，扩展了Python的字符串处理能力。

Python配置C API改进提案摘要 PEP 741提出改进Python C API，提供更灵活的配置方式。主要特性包括： 新增PyInitConfig不透明结构体及相关API，统一预初始化和初始化配置接口 支持运行时获取和修改配置选项，替代将被移除的全局变量 简化嵌入Python的方式，不再区分"Python"和"隔离"两种模式 新增模块添加API PyInitConfig_AddModule() 提供基于文本的配置接口，避免ABI兼容性问题 改进动机包括：修复安

摘要 PEP 709 提出将Python中的列表、字典和集合推导式从编译为嵌套函数改为内联实现。这一优化通过将推导式代码直接嵌入到定义位置，并使用栈操作管理变量作用域，显著提升了运行效率。基准测试显示，简单推导式性能提升可达2倍，实际应用场景中也有11%的加速。虽然会带来一些可见行为变化（如locals()内容、回溯信息等），但保持了语义一致性且对用户代码影响极小。该提案已在CPython中实现，为广泛使用的推导式特性提供了更高效的实现方式。

协议类型，行为类似只读 TypedDict，但不要求运行时类型为 dict。允许这些值在类型已知时做类型检查，但很难写只读代码以接受更具体的变体：例如，值可能是子类型或限制于某些联合类型。此外，函数参数标记为只读（如用带只读项的 TypedDict），不仅类型检查器可见，用户也能明确知道函数不会修改输入，这通常是函数接口的理想属性。本 PEP 为 TypedDict 添加了新特性，检查 TypedDict 类型的代码需做适配，主要影响类型检查器。这自然想支持更广泛的类型，也涉及嵌套类型的处理。

Python PEP 749 摘要：PEP 649 的补充实现 本 PEP 对 PEP 649 的延迟注解求值机制进行补充规范，主要包含： 弃用计划：from __future__ import annotations 将保留至 Python 3.13 生命周期结束，之后逐步弃用并移除。 新增模块：引入标准库 annotationlib，提供注解工具集，包括格式枚举、前向引用类和辅助函数等。 行为统一：REPL 环境采用与模块相同的延迟求值机制，避免特殊处理。 包装器处理：明确 classmethod、fu

本PEP 702提出新增@warnings.deprecated()装饰器，用于标记Python类、函数或方法的弃用状态。该装饰器允许开发者提供弃用信息，并将在静态类型检查时触发警告，同时默认在运行时抛出DeprecationWarning。该提案旨在通过类型系统增强弃用检测能力，帮助开发者更早发现并迁移弃用API，解决当前仅依赖运行时警告的不足。装饰器支持对重载函数、TypedDict、属性等多种场景进行标记，并规定了类型检查器应检测的多种使用场景。该功能已有多语言实践支持，并能显著提升API迁移效率。

Python PEP 738: 支持Android平台摘要 本PEP提议在CPython中正式添加Android作为支持平台(Tier 3)，目标从Python 3.13开始实现。Android作为占据70%移动市场的操作系统，其重要性日益增长，而目前CPython尚不提供官方支持。技术上，Android基于Linux内核但使用Bionic C库，虽与Linux二进制不兼容，但大多数C代码(包括CPython)只需少量修改即可编译。 实施方案包括： 仅支持64位架构(arm64-v8a/x86_64) 最低

Python C API 整数导入导出规范 (PEP 757) 摘要 PEP 757 提出了标准化的 C API 来高效导入/导出 Python 整数(int)，解决现有扩展库(gmpy2/SAGE等)直接操作内部结构或使用临时格式的问题。规范包含： 布局API：PyLongLayout描述整数底层存储格式 导出API：PyLong_Export()将Python整数转为C结构，支持小整数优化 导入API：PyLongWriter_Create()从C数据构建Python整数 基准测试显示，新API在多数情

Python PEP 734 提案旨在标准库中引入多解释器支持，通过新增interpreters模块提供子解释器创建与管理功能。该提案是PEP 554的延续，核心内容包括： 提供Interpreter对象表示解释器实例 实现基础Queue类支持解释器间通信 新增concurrent.futures.InterpreterPoolExecutor 技术背景： CPython自1.5起支持多解释器 每个解释器拥有独立状态，但共享部分全局数据 通过C API可创建子解释器 动机： 使多解释器功能更易于Python