Skip to content

gh-140824: Build the math module as an extension package#152352

Open
serhiy-storchaka wants to merge 1 commit into
python:mainfrom
serhiy-storchaka:math-extpkg-proto
Open

gh-140824: Build the math module as an extension package#152352
serhiy-storchaka wants to merge 1 commit into
python:mainfrom
serhiy-storchaka:math-extpkg-proto

Conversation

@serhiy-storchaka

@serhiy-storchaka serhiy-storchaka commented Jun 26, 2026

Copy link
Copy Markdown
Member

Build math as a real extension package (math/__init__ and math/integer), so that math.integer is a genuine extension submodule instead of the _math_integer extension module patched at runtime to look like a submodule.

This removes the leftover sys.modules['_math_integer'], gives math.integer's functions a correct __module__, and drops the __name__/__module__ and _PyImport_SetModuleString workarounds.

How

  • Modules/makesetup now accepts dotted module names and decouples three attributes that were previously tied to a single Setup token: the registration name (math.integer), the on-disk path (math/integer), and the C init symbol. A package initializer is written with an explicit __init__ leaf (math.__init__).
  • Makefile.pre.in preserves sub-directories when staging into the build-tree dynload dir and when installing into lib-dynload.
  • Tools/build/check_extension_modules.py and Tools/build/generate_stdlib_module_names.py understand package and dotted submodule names (the submodule is excluded from sys.stdlib_module_names).
  • configure.ac/Setup.stdlib.in build the package through the normal module-detection machinery (MODULE_MATH_INTEGER_*).

Shared vs. builtin

Works both for the usual shared build and for builds where math is compiled into the interpreter as a builtin (Windows, WebAssembly):

  • A builtin package gets no __path__ from the import machinery, so math's exec slot sets an empty __path__ to mark it as a package and let the builtin math.integer be found.
  • A shared submodule must export PyInit_<last component> (PyInit_integer) for the dynamic loader, but in an all-static build every PyInit_* shares one symbol namespace where a bare last-component name would clash across packages. So the static inittab uses a symbol derived from the full dotted name (PyInit_math_integer), selected with Py_BUILD_CORE_BUILTIN; only one of the two symbols is compiled per build mode. PC/config.c registers the Windows builtin accordingly.

Testing

  • Default shared build: make, checksharedmods, and test_math/test_cmath/test_importlib/test_sys all pass.
  • All-static (builtin math) build: verified that import math.integer works and that only the unique PyInit_math_integer symbol is present in the binary.
  • Not built on Windows from my environment; PC/config.c mirrors the verified builtin path.

🤖 Generated with Claude Code

https://claude.ai/code/session_01R4YFmYjuT6XeiobFzeQjDp

Build math as an extension package (math/__init__ and math/integer) so
that math.integer is a genuine extension submodule instead of the
_math_integer extension module patched at runtime to look like one.  This
drops the sys.modules['_math_integer'] leak and gives math.integer's
functions a correct __module__.

Modules/makesetup now accepts dotted module names, mapping each to its
registration name, on-disk path and init symbol; a package initializer is
written with an explicit __init__ leaf (math.__init__).  Makefile.pre.in
keeps sub-directories when staging and installing shared modules, and
check_extension_modules.py and generate_stdlib_module_names.py handle
package and dotted submodule names.

The package works both for shared builds and for builds where math is a
builtin (Windows, WebAssembly): math's exec slot sets __path__ when the
import machinery does not, and the static inittab uses a symbol derived
from the full dotted name (PyInit_math_integer) to stay unique, selected
with Py_BUILD_CORE_BUILTIN.

ExtensionFileLoader.is_package() now mirrors FileLoader by returning False
for the "__init__" name itself, so that modulefinder (used by
Tools/freeze) does not recurse on an extension package.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant