Antoine Pitrou wrote:
"I don't really like the idea of complicating our build tools even more. Can't you simply prune the install tree yourself?"

In the embedded world, the (cross) compilation process is very complex and slow. Being able to disable features makes this task simpler.

Éric Araujo wrote: 
"The main issue with the proposed changes is that it redefines what “the Python standard library” is."

I disagree. It's a common practice that a vendor gives the user the choice to enable or disable some features. On Gentoo and FreeBSD, you can disable features like IPv6 or shared memory on some packages. I don't think that it's currently possible on Python, but I would not be surprised to be able to enable or disable some features.

Éric Araujo wrote: 
"Right now, users can mostly expect modules listed in the official Python docs to be available in their installation, regardless of how they got their Python."

How you get Python matters :-) Python documentations describes the vanilla flavor distributed at python.org. But the Python license allows to strip some features without changing the name of the Python.

--

0002-Add-an-option-to-disable-installation-of-test-module.patch is interested. I never understand why Python installs its test suite. Who use this test suite installed on the system? Maybe the packager of the module to test Python. Ok, but the test suite can then be removed.

I like the overall approach, by individual patches may be discussed. For example,  0008-Add-an-option-to-disable-expat.patch breaks Python XML modules. Are they still be installed? I mean the modules implemented in Python and relying on the expat Python module.

The changes should be be documented somewhere. In the Python documentation, or at least in the "devguide".