"Any additional module increases the maintenance cost for the Python core development team. The team has limited resources, reduced maintenance cost frees development time for other improvements." This really doesn't jibe with the "Hey guys we have tools to convert 2 to 3 so easily" and "we aren't breaking stuff." A good working library will continue to be a good working library until you break it.
"Modules in the standard library are generally favored and seen as the de facto solution for a problem. A majority of users only pick third-party modules to replace a stdlib module, when they have a compelling reason, e.g. lxml instead of xml. The removal of an unmaintained stdlib module increases the chances of a community-contributed module to become widely used."
First, part of the appeal of Python is that de facto standard. Recall all of the XKCD comics about it. I don't have to make choices about which of seventeen different Perl libraries I can maybe find that exist on CPAN and try to decide between them. This is one of the reasons why I fled Perl.
Second, why do we want a community-contributed module to be widely used? That's stated as a goal but without explanation. If there is a widely used community-contributed module that is better, put it in the standard library.
I could almost like "A lean and mean standard library benefits platforms with limited resources like devices with just a few hundred kilobyte of storage ..." except that there ought to be a mechanism for cutting parts out of the standard library anyway if they aren't being used by your particular space-starved platform. This doesn't actually solve the problem being posed. It isn't the sunau module that is making or breaking the memory budget -- find a way to dis-include unused stdlib modules for projects.
Listen to this: "The crypt module has fundamental flaws that are better solved outside the standard library." So either fix them or move whatever is being used into the standard library.
Now, we can quibble about individual modules (I am rather fond of cgi, it's just so damned handy if you want to make something small without hauling in entire frameworks), but that misses the point -- the standard library exists to free us from the burden of sifting through N implementations of whatever it is we want to solve, where the complete coverage of the issue varies from "the happy path" to "eighty percent of the problem but sadly you need to do work in the twenty percent not covered."
> Second, why do we want a community-contributed module to be widely used? That's stated as a goal but without explanation. If there is a widely used community-contributed module that is better, put it in the standard library.
I think the reasoning is that offering a flawed version in the standard library can prevent an alternative from being written and gaining adoption.
I think that's it. If you haven't heard of Requests, you might re-implement it yourself from the standard library. That's totally possible (and I had to do that back in the dark days before Requests and pip), but not something most people should be doing.
The tl;dr is that if you move a package into the standard library then you are restricted by the python feature release schedule (was every 18 months, now annual) and backwards compatibility requirements (see https://peps.python.org/pep-0387/).
> A good working library will continue to be a good working library until you break it.
This isn't necessarily true, it depends on what the library is targeting. Sure, you could try to use a libcurl 7.9 from 2001 but there's going to be security bugs abound and it's going to be a pain to send verbs like PUT that some APIs expect. Standards, security concerns and paradigms change over time and can easily break good working libraries that are unmaintained.
However, things like a json parser and writer are relatively stable and don't need many changes over time because of the stability of the format.
"Any additional module increases the maintenance cost for the Python core development team. The team has limited resources, reduced maintenance cost frees development time for other improvements." This really doesn't jibe with the "Hey guys we have tools to convert 2 to 3 so easily" and "we aren't breaking stuff." A good working library will continue to be a good working library until you break it.
"Modules in the standard library are generally favored and seen as the de facto solution for a problem. A majority of users only pick third-party modules to replace a stdlib module, when they have a compelling reason, e.g. lxml instead of xml. The removal of an unmaintained stdlib module increases the chances of a community-contributed module to become widely used."
First, part of the appeal of Python is that de facto standard. Recall all of the XKCD comics about it. I don't have to make choices about which of seventeen different Perl libraries I can maybe find that exist on CPAN and try to decide between them. This is one of the reasons why I fled Perl.
Second, why do we want a community-contributed module to be widely used? That's stated as a goal but without explanation. If there is a widely used community-contributed module that is better, put it in the standard library.
I could almost like "A lean and mean standard library benefits platforms with limited resources like devices with just a few hundred kilobyte of storage ..." except that there ought to be a mechanism for cutting parts out of the standard library anyway if they aren't being used by your particular space-starved platform. This doesn't actually solve the problem being posed. It isn't the sunau module that is making or breaking the memory budget -- find a way to dis-include unused stdlib modules for projects.
Listen to this: "The crypt module has fundamental flaws that are better solved outside the standard library." So either fix them or move whatever is being used into the standard library.
Now, we can quibble about individual modules (I am rather fond of cgi, it's just so damned handy if you want to make something small without hauling in entire frameworks), but that misses the point -- the standard library exists to free us from the burden of sifting through N implementations of whatever it is we want to solve, where the complete coverage of the issue varies from "the happy path" to "eighty percent of the problem but sadly you need to do work in the twenty percent not covered."