I think Python needs much fewer packages in its standard library:
- array: everyone uses numpy for the same purposes
- bisect: very niche feature, not a good fit for standard library
- glob: should probably be part of os
- graphlib: why is it part of the standard library? even if you need to work with graphs, chances are you have different requirements or data format
- shlex: again, not really necessary in standard library (unless it's used in shutil, I don't know)
- statistics: should be handled by scipy
And that's just the modules mentioned in this article. There are tons of other modules that are outdated, unused, don't fit into standard library: getopt, curses, urllib (everyone uses requests), xml*, html, tkinter.
What Python should be doing is deprecating those modules and/or moving them outside of the standard library. Not adding more of them.
Sorry to pile-on on the disagreements, but I also try to keep my scripts as external dependency-free as possible (at the expense of reinventing the wheel a bit) so that I minimize supply-chain attacks, and to keep things as future-proof as possible.
For that, some of the included libraries really ease the pain of having to reinvent things like text-wrapping, special cases when iterating over things, creating TUIs, etc.
The more you read the docs, the more you appreciate the thought and effort of the Python developers in making things useful and convenient for everyone.
iirc requests is actually a wrapper for urllib. And there are certainly many scripts using urllib directly to avoid having an out-of-stdlib dependency. The API is not that bad.
They do sort out dead batteries [1]. But pretty much every case you've listed is not exactly dead, but more like a philosophical disagreement.
For example some modules are not what they seem to be; graphlib doesn't purport to be a general graph library and statistics doesn't mean to replace scipy. They are just groups for otherwise independent bits of code, named so that similar future code can be grouped together. In some cases you have a waaaaaay too high threshold for "unused" modules, for example [1] kept getopt because it mirrors a popular C library.
> kept getopt because it mirrors a popular C library
It's an excellent reason to keep it as a separately maintained module. Having in the standard library two modules for the same purpose just adds to the confusion.
You can also use numpy to use stdev, and i would argue thay in most contexts where you need to compute stdev you are also likely to use other numpy and scicpy features
Array - What's the use case here? (And I'm not being snarky or even critical.)
My usage is generally lists for small stuff where I don't care about performance, and pandas/numpy for analysis. So maybe array is either if I don't want numpy, or if I am doing something real and large and list performance would truly be a problem?
Also, I looked for a PEP to answer these questions and couldn't find it. (The one I found was very old). Or any stats on performance improvements?
I agree with some of these, and some could be consolidated, but the features of `glob` and `shlex` are useful for writing scripts, which I think is a common use for Python. Seems to me that leaving them in is reasonable.
I also think having basic statistic computations is useful. There are people who may want to calculate simple statistics without adding a whole dependency.
I use the array module to make the Python/C extension interface easier, to save space for big data sets, and (with from/to), simplify I/O.
I don't want a dependency on NumPy, especially as I don't need any other feature of NumPy beyond storing a homogeneous, resizeable vector of simple data types.
For one thing, you can pry Tkinter from my cold dead hands. For another, I used array just last week.
This whole "no one is using it so throw it away" culture is part of the improving-to-death of the modern Python ecosystem. I think it must come from the Python 3 fiasco. It's become fashionable in a subset of Python community to aggressively deprecate working code.
Exactly! I use fnmatch a lot to translate glob strings to regexes (in a VFX company, I'm a developer for a Houdini and in-house software pipeline).
Being able to provide solid globbing options to users in any scenario that is 'path-y' can provide massively more power to them, in lots of different cases I'd say.
glob could be part of os (or maybe even pathlib) that is true. But I have used all except graphli at one point or another with shlex being the most regular.
In the case of graphlib, I somewhat agree - graph functions are necessary for many modern applications, and the choice of functions supported by graphlib is... interesting. It would probably make more sense to either extend them or just replace it with a more useful library.
- array: everyone uses numpy for the same purposes
- bisect: very niche feature, not a good fit for standard library
- glob: should probably be part of os
- graphlib: why is it part of the standard library? even if you need to work with graphs, chances are you have different requirements or data format
- shlex: again, not really necessary in standard library (unless it's used in shutil, I don't know)
- statistics: should be handled by scipy
And that's just the modules mentioned in this article. There are tons of other modules that are outdated, unused, don't fit into standard library: getopt, curses, urllib (everyone uses requests), xml*, html, tkinter.
What Python should be doing is deprecating those modules and/or moving them outside of the standard library. Not adding more of them.