On Tue, Jun 30, 2020 at 12:00 AM <redrad...@gmail.com> wrote: > > Steven D'Aprano wrote: > > 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. > > 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) >
Or perhaps you didn't get his point, which is that that would be a really bad thing to do. ChrisA _______________________________________________ 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/KIIGNJ6FYYJFGB4RWHY6X564NF77DDAW/ Code of Conduct: http://python.org/psf/codeofconduct/
