On Mon, Jun 29, 2020 at 10:20:40AM -0000, redrad...@gmail.com wrote:
> Why I want that ?
> Okay, here are the reasons:
> 1) Security issue, should be fixed as soon as possible without waiting
> 2 months or 1 year for next CPython release
That is an excellent argument, but is that *our* responsibility?
There are many third party distributors that bundle Python and can
provide a much faster bug fix schedule, e.g. Anaconda, Red Hat, other
Linux distributions. (Apologies if I have missed anyone.)
Some of them have more resources in time, money and available manpower
than we have.
If you want security fixes faster than the Python-Devs are capable of
releasing them, perhaps you ought to pay a third-party?
> 2) Modules could be evolved independently that will allow to use some
> features of package earlier ... (crucial in our "Fast" World)
You say "crucial", I say "terrible". Our "fast world" is not something
we should be encouraging. It is bad for people and bad for technology.
Libraries in the std lib should not be evolving fast. Stability is more
important than rapid development, and if a library is so experimental
that it needs rapid development, then it is too experimental to be in
the std lib.
Third-party libraries can evolve as fast or as slow as they want; the
Python std lib is under tension between people who want faster evolution
and people who want stability, and we have to balance those two desires.
As a compromise between "change once a month" and "change once a
decade", I think Python's release cycle is not too bad.
> 3) If library modularized I can remove parts of it on constrained
> environments (microcontroller) or in environments where we try to same
> each byte of disk memory Interfaces between modules would be thinner
> and visible that will allow to download as many packages as need for
> this module or library
You can already do that. There are at least two currently maintained
Pythons for small systems, MicroPython and CircuitPython. There may be
others.
The question is not whether Python's standard library can be split up,
but whether we should force it to be split up for *everyone*, making
everyone's life more complicated in order to simplify the needs of a
minority of developers.
I have written a lot of code that has to run on older versions or
installations without third-party libraries, so I have lots of
feature-detection code:
try:
min([1], key=lambda x: None)
except TypeError:
# Current system is too old to support key functions.
# Create our own basic version.
...
At the beginning, it's lots of fun to come up with clever ways to detect
features which might be missing, and then find a work around. But it
gets tiresome and painful very quickly.
It is much better to work with a known environment: if I am running in
Python 3.9, then *all these libraries and features come in a bundle*. If
everything could change independently, then we would need feature-
detection and version checks everywhere. That is not enjoyable, and it
increases the complexity for *everyone* even when they get no benefit.
--
Steven
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/F7EFK5IIFG22NCKSW43OGR3IULKUO3SB/
Code of Conduct: http://python.org/psf/codeofconduct/
