On 07/05/2016 10:05 AM, Chris Angelico wrote: > On Tue, Jul 5, 2016 at 5:53 PM, Petr Viktorin <encu...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
