My first, and primary, programming language was C# which includes probably too large a standard library. It was definitely a surprise to see how minimal/simple other standard libraries are!
But they're there. I would much rather have a stdlib option which isn't as good as the most popular third party solution, than not have an stdlib option at all. You can't always count on being able to install stuff from pypi, but you can always count on the stdlib being present.
Broadly speaking, maintaining a big std lib is a huge amount of work, so it makes sense that a language team is conservative about adding new surface to a stb lib which they will then have to maintain for a long time.
The work involved in maintaining a standard library is things like bug fixes. A larger standard library (or multi versions) means there's more likely to be bugs. You also have performance improvements, and when new versions of the language come out which has features to improve performance, you will most likely want to go back through and refactor some code to take advantage of it. You will also want to go through and refactor to make code easier to maintain. All of this just gets harder with a larger surface.
And the more stuff you pack into the standard library the more expertise you need on the maintenance team for all these new libraries. And you don't want a standard library that is bad, because then people won't use it. And then you're stuck with the maintenance burden of code that no one uses. It's a big commitment to add something to a standard library.
Every library is a liability especially in terms of api. There are many example where the first take on a problem within a std lib was a bad choice and required a major overhaul. Once something is in standard library it’s literally impossible to take it back without breaking the world if you don’t control api consumers
Yes, in python they break something at every release now. It's terrible. It mostly is because they remove modules from their standard library for no good reasons.
For example they've removed asyncore, their original loop-based module before the async/await syntax existed. All the software from that era needs a total rewrite. Luckily in debian for now the module is provided as a .deb package so I didn't have to do the total rewrite.
edit: as usual on ycombinator, dowvotes for saying something factually true that can be easily verified :D
The code is under the open-source PSF license. You can vendor or repackage it as you wish rather than rewriting your dependents. The removal is mostly about ensuring that nobody will try to hold them responsible for any more maintenance (plus they can, for example, drop tests and have a faster running test suite).
The thread is about the code in the std lib being a huge amount of work because the code in the std lib needs to be kept working with new language releases.
And then you answered about downstream code breakage totally outside the std lib.
What would that entail, just a package whitelist? A few renamed packages? In the python 3 transition they renamed urllib2 to just urllib, but now it's almost a dead battery too and you want to use requests.
Honestly the problem was they did not go far enough. They hoped to have a minimal churn switch to avoid getting locked into bikeshedding for the rest of time. However, there was so little user user facing improvements that the required change hardly seemed worth porting. They also failed to initially offer any automatic porting tooling which could have increased adoption.
I will be forever mad that they did not use that as a breaking opportunity to namespace the standard library. Something like: `import std.io` so that other libraries can never conflict.
