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

Petr Viktorin encukou at gmail.com
Tue Jul 5 05:04:48 EDT 2016


On 07/05/2016 10:05 AM, Chris Angelico wrote:
> On Tue, Jul 5, 2016 at 5:53 PM, Petr Viktorin <encukou at gmail.com> wrote:
>> If packages had a way to opt-out of needing the whole standard library,
>> and instead specify the stdlib subset they need, answering questions
>> like "will this run on my phone?" and "what piece of the stdlib do we
>> want to port next?" would be easier.
> 
> On the flip side, answering questions like "what version of Python do
> people need to run my program" become harder to answer, particularly
> if you have third-party dependencies. (The latest version of numpy
> might decide that it's going to 'import statistics', for instance.)

That question is already hard to answer. How do you tell if a library
works on Micropython? Or Python for Android?

I'm not arguing to change the default; if the next version of numpy
doesn't do anything, nothing should change. However, under the status
quo, "Python 3.4" means "CPython 3.4 with the full stdlib, otherwise all
bets are off", and there's no good way to opt in to more granularity.


> One of the arguments against splitting the stdlib was that corporate
> approval for software is often hard to obtain, and it's much easier to
> say "I need approval to use Python, exactly as distributed by
> python.org" than "I need approval to use Python-core plus these five
> Python-stdlib sections".

I'm not arguing against "Python, exactly as distributed by python.org"
not including all of stdlib.
I would like making stripped-down variants of CPython easier, and to
make it possible to opt-in to use CPython without all of stdlib, so that
major problems with stdlib availablility in other Python implementations
can be caught early.
Basically, instead of projects getting commits like "Add metadata for
one flavor of Android packaging tool", I'd like to see "Add common
metadata for Android, IPhone, PyInstaller, and minimal Linux, and make
sure the CPython-based CI smoke-tests that metadata".

Also, I believe corporate approval for python.org's Python is a bit of a
red herring – usually you'd get approval for Python distributed by
Continuum or Red Hat or Canonical or some such. As a Red Hat employee, I
can say that what I'm suggesting won't make me suffer, and I see no
reason it would hurt the others either.



More information about the Python-Dev mailing list