[Python-Dev] Breaking up the stdlib (Was: release cadence)

Paul Moore p.f.moore at gmail.com
Tue Jul 5 16:02:03 EDT 2016

On 5 July 2016 at 19:01, Petr Viktorin <encukou at gmail.com> wrote:
> There are people who want to cut out what they don't need – to build
> self-contained applications (pyinstaller, Python for Android), or to
> eliminate unnecessary dependencies (python3-tkinter). And they will do
> it with CPython's blessing or without.
> It would be much better for the ecosystem if CPython acknowledges this
> and sets some rules (like "here's how you can do it, but don't call the
> result an unqualified Python").

That doesn't sound unreasonable in principle. As a baseline, I guess
the current policy is essentially:

You can build your own Python installation with whatever parts of the
stdlib omitted that you please. However, if you do this, you accept
responsibility for any consequences, in terms of 3rd-party modules not
working, or even stdlib breakage (for example, we don't guarantee that
parts of the stdlib may not rely on other parts).

That's pretty simple, both to state and to adhere to. And it's
basically the current reality. What I'm not clear about is what
*additional* guarantees people want to make, and how we'd make them.
First of all, Python's packaging ecosystem has no way to express "this
package won't work if pathlib isn't present in your stdlib". It seems
to me that without something like that, it's pretty hard to support
anything better than the current position with regard to 3rd party
modules. Documenting stdlib inter-dependencies may be possible, but I
wouldn't like to make "X doesn't depend on Y" a guarantee that's
subject to backward compatibility rules.

Maybe the suggestion is to provide better tools for people wanting to
*build* such stripped down versions? That might be a possibility, I
guess. I don't know much about how people build their own copies of
Python to be able to comment.

So I guess my question is, what is the actual proposal here? People
seem to have concerns over things that aren't actually being proposed
- but without knowing what *is* being proposed, it's hard to avoid

More information about the Python-Dev mailing list