After thinking about this proposal a bit more, and by gathering your feedback (thank you), I think I will actually reject my own proposal. One major reason is that, unless I’m doing CTFs or other “quick” tasks, I indeed don’t see a real need for a sanitized output without filenames when I can already do it with existing tools. Sure there are times when it’s annoying but I would likely spend the same time typing python -m ... or echo text | ....
There is definitely value in having a CLI for Windows for, e.g., computing file digests without having to use unreadable calls but as I personally won’t be the one affected, it becomes less convincing to myself.
Finally, it was historically proposed (I actually forgot to look at the issue tracker this time) in hashlib command line interface · Issue #70675 · python/cpython · GitHub but, despite many core devs supporting this addition, it was eventually decided to reject it. Quoting Guido:
I prefer not to go down this road. The modules that do this where I use it
are typically Python specific, e.g. pdb or timeit. In the past we sometimes
had little main() functions in modules for testing but I think we have
better ways to test modules these days.
After reading that thread I also become less convinced. So thank you all for the valuable feedback and sorry for having taken your time for a dead proposal (I also don’t think I would support future CLI proposal for those specific modules).
Even if I rejected my own prposal, I will reply to some of your questions:
- Why not use a cross platform shell if you want a cross platform shell
My main concern (and me being annoyed with existing tools) is that the output sometimes need sanitization before I can directly use it. So using a cross platform shell won’t help if the tools themselves have not the best output.
- Why not use
python -c
Computing file digests with python -c is honestly painful (you can’t just pass filepaths, you’ll need to pass a file object). And the function for comparing file digests is a combination of two functions, (hashlib.file_digest and hmac.compare_digest).
So, I wouldn’t recommend doing it and would rather suggest creating a real file script which is also annoying. My proposal was about skipping that second annoying thing.
- Why not use python -m fire module
For HMAC, it should work because we have hmac.digest which computes the digest (though only bytes…) but not for the other functions as you either get a HMAC or a HASH object and not a hexadecimal readable string. Unless you can call a method on the object you constructed via fire (I don’t know if it’s possible), it won’t work (that is, unless you can do hashlib.new(algorithm, data).hexdigest()).
any “Let’s add a CLI for x” proposal is synonymous with “Let’s re-implement our own Python version of coreutils + anything else that’s reasonably standard and put it in the standard library for people who want a cross platform shell but won’t use a cross platform shell”.
I disagree here but I don’t think I will be able to convince you here. I think it’s also fine to offer similar but centralized tools whose implementation solely depends on Python itself. There are also some modules that do need a CLI IMO (e.g., ast or dis) because they are very Python specific as Guido mentioned.
Powershell example below
If this is the alternative to python -m base64, then I wouldn’t want it and I am happy that python -m base64 exists.
Is it expected that anyone would use the further configuration possible from a CLI.
Honestly, no. Which is one of the reason that made me hesitate in the end.