Post

- packaging tools (pip, zipapp)

Some of these, just need a registered command, like pip has (`python -m pip` vs `pip` ), but conditionally registering a cli command is hard (gzip would likely clash, others wouldn't).

Some of these could be like go `python test` a sort of command invoker without Makefile.

Some of these really need a gui, think complex but used once every few years

Some of the secret commands are actually in the docs but not in the distribution, e.g. the unified diff code.

The strongest case for any of this is to have

python test
python document
python build
python format

But for these "SDLC" type commands, python's build is either doesn't exist (format) or the non-stdlib library is massively better (pytest)

There is a suite of internet tools (telnetlib, imaplib, etc) for whom I don't know who the audience is. curl does all of that better and the built in clients are thin and dated- the types of servers popular on the internet keep changing with fashion and security concerns. ftplib exists but no sftplib support. These all need a gui, but the gui would be so large as to dwarf the stdlib part.

Also the way these tools re discovered is websearch and grep, not `--help` and grep returns all the left over debugging code (using dunder main blocks as an ad hoc unit test) and jokes and ephemera like antigravity and `this`

The amount of noise in the 'here are 100s of hidden tools in python', imho makes that a bad way to surface the good parts.

And the final cluster of tools are essentially cross-platform tooling, ie. all the things you use in bash but aren't bash builtin. This is super hit or miss as a solution (git bash and WSL) are what people usually use. Some of the tools are big and complicated (sed, grep, etc). Simulating linux shell in python, but on non-linux machines should have been its own product and I think python went down that path accidentally (with several compression commands but other tool categories missing)