Steven D'Aprano 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
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
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:
On Mon, Jun 29, 2020 at 10:20:40AM -0000, redradist@gmail.com wrote: 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? 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. 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.
Seems like you did not get my point ... ( I do not ask to remove or replace Python standard library, but to split it on two versions (aka standard, like .NET Standard, Rust libcore and libstd) Modularization would be also nice, but it requires time ... Claim that all Python should at least support libcore (Core Library) make whole infrastructure more uniform libcore could be all packages written in python and that do not access os resource and essential for ecosystem libstd - all other standard module libcore and libstd it is small step to modularization and standartization whole Python ecosystem