CPython 3.15 Lazy Import 修复解析非模块命名空间下缓存全局加载的未解析问题【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython本篇文章围绕 CPython 仓库中一则核心内建Core and Builtins修复记录展开当通过exec()传入的普通字典而非真正的模块命名空间作为全局或内建命名空间时缓存的全局加载cached global loads可能产生未解析unresolved的 lazy import 对象。文章将结合lazy import机制的语言文档、字节码特化specialization实现与回归测试还原问题成因、修复验证路径并给出开发者在使用自定义命名空间时的实践建议。修复记录原文关联文档 Misc/NEWS.d/next/Core_and_Builtins/2026-06-19-16-40-01.gh-issue-151619.35yyJW.rst 记录了本次修复的核心内容Fix an issue where using non-module global or builtin namespaces (such as dictionaries passed toexec) could cause cached global loads to produce unresolvedlazy imports.翻译过来即修复了一个问题——当使用非模块的全局或内建命名空间例如传给exec()的字典时缓存的全局加载可能产生未解析的 lazy import。这条记录虽短却牵涉到 Python 3.15 新增的 lazy imports 特性与解释器自适应特化adaptive specialization机制之间的交互。下文逐层拆解。背景Python 3.15 的 Lazy Imports 机制语言层面的 lazy import依据 Doc/reference/simple_stmts.rst 中Lazy imports章节同时参考 PEP 810 规范lazy是一个软关键字soft keyword只有紧邻import或from语句出现时才具有特殊含义lazy import json import sys print(json in sys.modules) # False - json module not yet loaded # 首次使用触发加载 result json.dumps({hello: world}) print(json in sys.modules) # True - now loaded核心语义包括带lazy前缀的 import 不会立即加载模块而是把一个lazy 代理对象绑定到名字上模块在首次使用该名字时才真正加载lazy import只允许出现在模块作用域在函数、类体或try/except/finally块中使用会抛出SyntaxErrorlazy from module import *是语法错误future语句不能被 lazy使用lazy from ... import时每个导入的名字都绑定一个 lazy 代理对象第一次访问其中任意名字会触发整个模块的加载但只解析被访问的那个名字其余名字仍保持代理状态若模块加载过程出错如ImportError、SyntaxError异常在首次使用 lazy import 时抛出而不是在 import 语句处。该特性在文档中以.. versionadded:: 3.15标记属于 Python 3.15 的语言新特性。解释器层的 lazy 代理对象代理对象的实现位于 Objects/lazyimportobject.c。_PyLazyImport_New()创建PyLazyImportObject其结构体保存了lz_builtins创建时的内建命名空间引用lz_from被导入的模块名lz_attr可选的fromlist字符串或元组lz_code/lz_instr_offset原始 import 位置的帧信息用于在解析失败时定位精确的源码行列。该类型提供了resolve()方法内部调用_PyImport_LoadLazyImportTstate其类型文档明确写道Instances of this object accessed from the global scope will be automatically imported based upon their name and then replaced with the imported value.也就是说在全局作用域访问到 lazy 代理对象时解释器应当自动完成导入并把代理对象替换为真实的导入值——这正是本次 NEWS 条目中未解析 lazy import问题的对照面修复前的某些路径下这个自动解析并替换的约定被打破了。问题剖析缓存全局加载为什么会产出未解析的 lazy importLOAD_GLOBAL 的自适应特化Python 解释器对字节码执行实施自适应特化。LOAD_GLOBAL指令在 Python/bytecodes.c 中被定义为一个宏展开为LOAD_GLOBAL _SPECIALIZE_LOAD_GLOBAL counter/1 globals_version/1 builtins_version/1 _LOAD_GLOBAL _PUSH_NULL_CONDITIONAL其特化家族包含两个快速变体_LOAD_GLOBAL_MODULEPython/bytecodes.c直接从全局字典按索引读取条目_LOAD_GLOBAL_BUILTINSPython/bytecodes.c 起从内建字典按索引读取条目。这些特化形式依赖_GUARD_GLOBALS_VERSION与内建版本守卫通过检查PyDictKeysObject的dk_version字段来判断字典结构是否变化。只要版本号匹配特化代码就跳过通用查找直接从缓存的条目索引处取回对象——这就是缓存全局加载的含义。快速路径与慢速路径的分界通用未特化的全局加载入口是_PyEval_LoadGlobalStackRef位于 Python/ceval.cif (PyAnyDict_CheckExact(globals) PyAnyDict_CheckExact(builtins)) { _PyDict_LoadGlobalStackRef((PyDictObject *)globals, (PyDictObject *)builtins, name, writeto); ... } else { /* Slow-path if globals or builtins is not a dict */ /* namespace 1: globals */ if (PyMapping_GetOptionalItem(globals, name, res) 0) { ... } ... }当globals与builtins都是精确的dict时走_PyDict_LoadGlobalStackRef快速路径实现见 Objects/dictobject.c基于哈希直接查找否则例如 globals 是自定义 mapping走基于PyMapping_GetOptionalItem的慢速路径。问题成因结合上述机制可以还原问题链以下为基于源码结构的推断性描述通过exec()传入的命名空间是普通字典它不是真正的模块__dict__却依然满足PyAnyDict_CheckExact检查解释器会对函数体内的LOAD_GLOBAL进行特化缓存全局/内建字典的版本号并按索引读取当 lazy import 代理对象在特化之后被放入该字典例如globals()[name] ...或__builtins__[name] ...某些缓存路径未能触发 lazy 代理的自动解析直接把未解析的代理对象作为全局加载结果返回破坏了访问即解析的语义约定。换句话说修复的目标是确保缓存全局加载在任何命名空间形态下都不会漏掉 lazy import 的 reification实体化步骤。回归测试两个 exec 命名空间场景的验证针对本次修复仓库在 Lib/test/test_lazy_import/init.py 中提供了两个高针对性的回归测试分别覆盖全局字典与内建字典两种非模块命名空间。测试一向 exec 全局字典注入 lazy importtest_add_lazy_to_exec_globals_after_specialization测试位于 Lib/test/test_lazy_import/init.py核心流程如下source import sys import types lazy from test.test_lazy_import.data import basic2 assert test.test_lazy_import.data.basic2 not in sys.modules class C: pass sneaky C() sneaky.x 1 def f(): t 0 for _ in range(5): t sneaky.x return t f() globals()[sneaky] globals()[basic2] assert f() 210 print(OK) ns {__name__: lazy_exec_globals} exec(source, ns)关键点拆解命名空间ns是传给exec()的普通字典__name__被设置为lazy_exec_globals属于非模块命名空间函数f()内部循环访问sneaky.x这会使LOAD_GLOBAL sneaky被自适应特化并缓存第一次调用f()后globals()[sneaky] globals()[basic2]将 lazy 代理解析出的模块basic2替换进全局字典的同一位置第二次调用f()必须返回210即 5 × 42对应basic2模块中x 42证明特化之后的缓存全局加载最终读到的是解析后的真实值而不是未解析的 lazy 代理。测试二向内建字典注入 lazy importtest_add_lazy_to_exec_builtins_after_specialization测试位于 Lib/test/test_lazy_import/init.py场景从全局字典换成了内建字典import builtins source import sys import types lazy from test.test_lazy_import.data import basic2 assert test.test_lazy_import.data.basic2 not in sys.modules class C: pass sneaky C() sneaky.x 1 __builtins__[sneaky] sneaky del sneaky def f(): t 0 for _ in range(5): t sneaky.x return t f() __builtins__[sneaky] globals()[basic2] assert f() 210 print(OK) ns {__name__: lazy_exec_builtins, __builtins__: builtins.__dict__.copy()} exec(source, ns)该测试把sneaky先通过__builtins__[sneaky]注入内建字典特化函数f()后再把 lazy import 解析出的basic2放回内建字典同一位置同样断言f() 210。两条测试分别从LOAD_GLOBAL_MODULE与LOAD_GLOBAL_BUILTINS两个特化方向的缓存路径上验证了修复效果。这两个测试都通过subprocess独立子进程运行并断言 stdout 含OK属于support.requires_subprocess()约束的进程级验证。相关源码调用链速览为便于读者继续深入这里汇总本主题涉及的关键实现位置环节位置作用语言规范Doc/reference/simple_stmts.rstlazy关键字语义、作用域限制、__lazy_modules__兼容模式代理对象类型Objects/lazyimportobject.cPyLazyImportObject结构、resolve()、自动解析文档解析执行Python/import.c_PyImport_LoadLazyImportTstate加锁、循环导入检测、实际导入全局加载入口Python/ceval.c_PyEval_LoadGlobalStackRef快速/慢速路径分流特化指令Python/bytecodes.cLOAD_GLOBAL宏与_LOAD_GLOBAL_MODULE特化形式字典快速查找Objects/dictobject.c_PyDict_LoadGlobalStackRef导入模式枚举Include/import.hPyImport_LazyImportsModeLAZY_NORMAL/LAZY_ALL回归测试Lib/test/test_lazy_import/init.pyexec 全局/内建命名空间下特化后的 lazy import 解析对开发者的实践建议exec()自定义命名空间与 lazy import 的组合需要版本前提lazy imports 是 Python 3.15 新增特性本文讨论的修复亦属于 3.15 开发周期NEWS 目录next/Core_and_Builtins。在 3.15 的正式版本中exec(source, ns)搭配lazy关键字或模块级__lazy_modules__兼容模式应能正确解析低于 3.15 的版本不存在该关键字也不受此问题影响。理解访问即解析约定lazy 代理对象在全局作用域被读取时应被自动替换为真实值。若你在自定义命名空间中手动搬运、缓存或序列化这些代理对象应意识到其解析时机取决于首次全局访问而不是赋值动作本身。运行回归测试验证环境可单独执行 lazy import 测试套件确认行为./python -m test test_lazy_import其中test_add_lazy_to_exec_globals_after_specialization与test_add_lazy_to_exec_builtins_after_specialization即为本修复的直接验证用例需子进程支持。编写自定义映射命名空间时注意慢速路径如果exec()的 globals 不是精确dict例如自定义Mapping解释器会走PyMapping_GetOptionalItem慢速路径特化守卫PyDict_CheckExact检查会使其失效回退。此时行为符合通用映射语义但性能低于 dict 路径。小结本次修复的核心价值在于补齐了 lazy imports 特性与解释器自适应特化之间的一个边界非模块命名空间exec 字典下的缓存全局加载必须保证 lazy 代理对象的自动解析语义不被绕过。从语言文档、代理对象实现、特化指令到两条进程级回归测试仓库提供了完整、可验证的证据链。对于在 3.15 上使用lazy import与exec()自定义命名空间的开发者这一修复消除了拿到未解析代理对象的隐患使 lazy imports 在嵌入脚本、动态执行等场景下同样可靠。【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CPython 3.15 Lazy Import 修复解析：非模块命名空间下缓存全局加载的未解析问题
CPython 3.15 Lazy Import 修复解析非模块命名空间下缓存全局加载的未解析问题【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython本篇文章围绕 CPython 仓库中一则核心内建Core and Builtins修复记录展开当通过exec()传入的普通字典而非真正的模块命名空间作为全局或内建命名空间时缓存的全局加载cached global loads可能产生未解析unresolved的 lazy import 对象。文章将结合lazy import机制的语言文档、字节码特化specialization实现与回归测试还原问题成因、修复验证路径并给出开发者在使用自定义命名空间时的实践建议。修复记录原文关联文档 Misc/NEWS.d/next/Core_and_Builtins/2026-06-19-16-40-01.gh-issue-151619.35yyJW.rst 记录了本次修复的核心内容Fix an issue where using non-module global or builtin namespaces (such as dictionaries passed toexec) could cause cached global loads to produce unresolvedlazy imports.翻译过来即修复了一个问题——当使用非模块的全局或内建命名空间例如传给exec()的字典时缓存的全局加载可能产生未解析的 lazy import。这条记录虽短却牵涉到 Python 3.15 新增的 lazy imports 特性与解释器自适应特化adaptive specialization机制之间的交互。下文逐层拆解。背景Python 3.15 的 Lazy Imports 机制语言层面的 lazy import依据 Doc/reference/simple_stmts.rst 中Lazy imports章节同时参考 PEP 810 规范lazy是一个软关键字soft keyword只有紧邻import或from语句出现时才具有特殊含义lazy import json import sys print(json in sys.modules) # False - json module not yet loaded # 首次使用触发加载 result json.dumps({hello: world}) print(json in sys.modules) # True - now loaded核心语义包括带lazy前缀的 import 不会立即加载模块而是把一个lazy 代理对象绑定到名字上模块在首次使用该名字时才真正加载lazy import只允许出现在模块作用域在函数、类体或try/except/finally块中使用会抛出SyntaxErrorlazy from module import *是语法错误future语句不能被 lazy使用lazy from ... import时每个导入的名字都绑定一个 lazy 代理对象第一次访问其中任意名字会触发整个模块的加载但只解析被访问的那个名字其余名字仍保持代理状态若模块加载过程出错如ImportError、SyntaxError异常在首次使用 lazy import 时抛出而不是在 import 语句处。该特性在文档中以.. versionadded:: 3.15标记属于 Python 3.15 的语言新特性。解释器层的 lazy 代理对象代理对象的实现位于 Objects/lazyimportobject.c。_PyLazyImport_New()创建PyLazyImportObject其结构体保存了lz_builtins创建时的内建命名空间引用lz_from被导入的模块名lz_attr可选的fromlist字符串或元组lz_code/lz_instr_offset原始 import 位置的帧信息用于在解析失败时定位精确的源码行列。该类型提供了resolve()方法内部调用_PyImport_LoadLazyImportTstate其类型文档明确写道Instances of this object accessed from the global scope will be automatically imported based upon their name and then replaced with the imported value.也就是说在全局作用域访问到 lazy 代理对象时解释器应当自动完成导入并把代理对象替换为真实的导入值——这正是本次 NEWS 条目中未解析 lazy import问题的对照面修复前的某些路径下这个自动解析并替换的约定被打破了。问题剖析缓存全局加载为什么会产出未解析的 lazy importLOAD_GLOBAL 的自适应特化Python 解释器对字节码执行实施自适应特化。LOAD_GLOBAL指令在 Python/bytecodes.c 中被定义为一个宏展开为LOAD_GLOBAL _SPECIALIZE_LOAD_GLOBAL counter/1 globals_version/1 builtins_version/1 _LOAD_GLOBAL _PUSH_NULL_CONDITIONAL其特化家族包含两个快速变体_LOAD_GLOBAL_MODULEPython/bytecodes.c直接从全局字典按索引读取条目_LOAD_GLOBAL_BUILTINSPython/bytecodes.c 起从内建字典按索引读取条目。这些特化形式依赖_GUARD_GLOBALS_VERSION与内建版本守卫通过检查PyDictKeysObject的dk_version字段来判断字典结构是否变化。只要版本号匹配特化代码就跳过通用查找直接从缓存的条目索引处取回对象——这就是缓存全局加载的含义。快速路径与慢速路径的分界通用未特化的全局加载入口是_PyEval_LoadGlobalStackRef位于 Python/ceval.cif (PyAnyDict_CheckExact(globals) PyAnyDict_CheckExact(builtins)) { _PyDict_LoadGlobalStackRef((PyDictObject *)globals, (PyDictObject *)builtins, name, writeto); ... } else { /* Slow-path if globals or builtins is not a dict */ /* namespace 1: globals */ if (PyMapping_GetOptionalItem(globals, name, res) 0) { ... } ... }当globals与builtins都是精确的dict时走_PyDict_LoadGlobalStackRef快速路径实现见 Objects/dictobject.c基于哈希直接查找否则例如 globals 是自定义 mapping走基于PyMapping_GetOptionalItem的慢速路径。问题成因结合上述机制可以还原问题链以下为基于源码结构的推断性描述通过exec()传入的命名空间是普通字典它不是真正的模块__dict__却依然满足PyAnyDict_CheckExact检查解释器会对函数体内的LOAD_GLOBAL进行特化缓存全局/内建字典的版本号并按索引读取当 lazy import 代理对象在特化之后被放入该字典例如globals()[name] ...或__builtins__[name] ...某些缓存路径未能触发 lazy 代理的自动解析直接把未解析的代理对象作为全局加载结果返回破坏了访问即解析的语义约定。换句话说修复的目标是确保缓存全局加载在任何命名空间形态下都不会漏掉 lazy import 的 reification实体化步骤。回归测试两个 exec 命名空间场景的验证针对本次修复仓库在 Lib/test/test_lazy_import/init.py 中提供了两个高针对性的回归测试分别覆盖全局字典与内建字典两种非模块命名空间。测试一向 exec 全局字典注入 lazy importtest_add_lazy_to_exec_globals_after_specialization测试位于 Lib/test/test_lazy_import/init.py核心流程如下source import sys import types lazy from test.test_lazy_import.data import basic2 assert test.test_lazy_import.data.basic2 not in sys.modules class C: pass sneaky C() sneaky.x 1 def f(): t 0 for _ in range(5): t sneaky.x return t f() globals()[sneaky] globals()[basic2] assert f() 210 print(OK) ns {__name__: lazy_exec_globals} exec(source, ns)关键点拆解命名空间ns是传给exec()的普通字典__name__被设置为lazy_exec_globals属于非模块命名空间函数f()内部循环访问sneaky.x这会使LOAD_GLOBAL sneaky被自适应特化并缓存第一次调用f()后globals()[sneaky] globals()[basic2]将 lazy 代理解析出的模块basic2替换进全局字典的同一位置第二次调用f()必须返回210即 5 × 42对应basic2模块中x 42证明特化之后的缓存全局加载最终读到的是解析后的真实值而不是未解析的 lazy 代理。测试二向内建字典注入 lazy importtest_add_lazy_to_exec_builtins_after_specialization测试位于 Lib/test/test_lazy_import/init.py场景从全局字典换成了内建字典import builtins source import sys import types lazy from test.test_lazy_import.data import basic2 assert test.test_lazy_import.data.basic2 not in sys.modules class C: pass sneaky C() sneaky.x 1 __builtins__[sneaky] sneaky del sneaky def f(): t 0 for _ in range(5): t sneaky.x return t f() __builtins__[sneaky] globals()[basic2] assert f() 210 print(OK) ns {__name__: lazy_exec_builtins, __builtins__: builtins.__dict__.copy()} exec(source, ns)该测试把sneaky先通过__builtins__[sneaky]注入内建字典特化函数f()后再把 lazy import 解析出的basic2放回内建字典同一位置同样断言f() 210。两条测试分别从LOAD_GLOBAL_MODULE与LOAD_GLOBAL_BUILTINS两个特化方向的缓存路径上验证了修复效果。这两个测试都通过subprocess独立子进程运行并断言 stdout 含OK属于support.requires_subprocess()约束的进程级验证。相关源码调用链速览为便于读者继续深入这里汇总本主题涉及的关键实现位置环节位置作用语言规范Doc/reference/simple_stmts.rstlazy关键字语义、作用域限制、__lazy_modules__兼容模式代理对象类型Objects/lazyimportobject.cPyLazyImportObject结构、resolve()、自动解析文档解析执行Python/import.c_PyImport_LoadLazyImportTstate加锁、循环导入检测、实际导入全局加载入口Python/ceval.c_PyEval_LoadGlobalStackRef快速/慢速路径分流特化指令Python/bytecodes.cLOAD_GLOBAL宏与_LOAD_GLOBAL_MODULE特化形式字典快速查找Objects/dictobject.c_PyDict_LoadGlobalStackRef导入模式枚举Include/import.hPyImport_LazyImportsModeLAZY_NORMAL/LAZY_ALL回归测试Lib/test/test_lazy_import/init.pyexec 全局/内建命名空间下特化后的 lazy import 解析对开发者的实践建议exec()自定义命名空间与 lazy import 的组合需要版本前提lazy imports 是 Python 3.15 新增特性本文讨论的修复亦属于 3.15 开发周期NEWS 目录next/Core_and_Builtins。在 3.15 的正式版本中exec(source, ns)搭配lazy关键字或模块级__lazy_modules__兼容模式应能正确解析低于 3.15 的版本不存在该关键字也不受此问题影响。理解访问即解析约定lazy 代理对象在全局作用域被读取时应被自动替换为真实值。若你在自定义命名空间中手动搬运、缓存或序列化这些代理对象应意识到其解析时机取决于首次全局访问而不是赋值动作本身。运行回归测试验证环境可单独执行 lazy import 测试套件确认行为./python -m test test_lazy_import其中test_add_lazy_to_exec_globals_after_specialization与test_add_lazy_to_exec_builtins_after_specialization即为本修复的直接验证用例需子进程支持。编写自定义映射命名空间时注意慢速路径如果exec()的 globals 不是精确dict例如自定义Mapping解释器会走PyMapping_GetOptionalItem慢速路径特化守卫PyDict_CheckExact检查会使其失效回退。此时行为符合通用映射语义但性能低于 dict 路径。小结本次修复的核心价值在于补齐了 lazy imports 特性与解释器自适应特化之间的一个边界非模块命名空间exec 字典下的缓存全局加载必须保证 lazy 代理对象的自动解析语义不被绕过。从语言文档、代理对象实现、特化指令到两条进程级回归测试仓库提供了完整、可验证的证据链。对于在 3.15 上使用lazy import与exec()自定义命名空间的开发者这一修复消除了拿到未解析代理对象的隐患使 lazy imports 在嵌入脚本、动态执行等场景下同样可靠。【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考