Can we decide if xx* modules are supposed to be packaged?

[thatch]

Bug report

Bug description:

(Observed on archlinux, but also present on docker run -ti python:3.13 so I assume it affects at least all Linux).

There are a number of demo/test extensions included (by accident?) when you run make install. For example, the one I found today:

• xx (Modules/xxmodule.c, not installed)
• xxlimited (Modules/xxlimited.c, installed)
• xxsubtype (Modules/xxsubtype.c, installed)

None of them appear listed in sys.stdlib_module_names and they also have invalid docs links like https://docs.python.org/3.12/library/xxlimited.html which leads me to think they weren't intended to be this public?

I'm maintainer of the stdlibs project (used by usort and ruff) and was spot-checking the differences with the stdlib-list project before filing an PR there.

CPython versions tested on:

3.12, 3.13

Operating systems tested on:

Linux

[thatch]

Related:

• _testbuffer installed
• _testcapi not installed
• _testconsole not installed
• _testinternalcapi installed

and

• _xxtestfuzz installed (but with wrong m_name on 3.11)
• _xxsubinterpreters not installed
• __phello__.spam installed (frozen now)
• sys.monitoring can't be imported in the normal way, yet is supposedly a module

I can come up with more :)

I think my request is twothreefold:

1. Can we decide if these modules/extensions are logically stdlib or not ("importable from a fresh install => yes?")
2. Can we decide if sys.stdlib_module_names should include them ("if previous answer is yes => yes?")
3. Can we maybe ship fewer of them, as the churn is some extra effort on import classification :)

[picnixz]

cc @vstinner @erlend-aasland

[vstinner]

Tools/build/generate_stdlib_module_names.py excludes test modules from sys.stdlib_module_names.

The ./configure script has a --disable-test-modules option to not install test modules.

By default, ./configure && make && make install installs the test package and test extensions.

---

xx (Modules/xxmodule.c, not installed)

Modules/xxmodule.c is an example. Only the source code is useful, not executing it:

Use this file as a template to start implementing a module that
also declares object types.

_testcapi not installed

./configure --prefix /opt/py314 && make && make install does install _testcapi.

_testconsole not installed

PC/_testconsole.c is specific to Windows.

There are a number of demo/test extensions included (by accident?) when you run make install.

For some users, including me, it's important to be able to run the test suite on the installed Python. If you don't want test modules, use ./configure --disable-test-modules.

None of them appear listed in sys.stdlib_module_names and they also have invalid docs links like https://docs.python.org/3.12/library/xxlimited.html which leads me to think they weren't intended to be this public?

sys.stdlib_module_names doesn't list test modules by design: https://docs.python.org/dev/library/sys.html#sys.stdlib_module_names

"Test modules are excluded."

---

By the way, Fedora splits Python 3.14 into multiple packages:

• python3.14: /usr/bin/python3.14 program
• python3.14-libs: stdlib and libpython
• python3.14-test: the test package, _testcapi, xxlimited, etc.
• etc.

[ericsnowcurrently]

FYI, _xxsubinterpreters is technically only meant for testing. Distributing it is not a problem, but also not important. Also note that it is only relevant in 3.12 and earlier.

[thatch]

I'll focus on documenting the differences then, it feels like there's interest in keeping cpython the way it is.

[erlend-aasland]

I'll focus on documenting the differences then, it feels like there's interest in keeping cpython the way it is.

As Victor mentioned, the build system already has functionality to disable the test modules:

$ ./configure --disable-test-modules && make install