I think it could be useful to have it. Some possible usage examples:
python -m datetime date today --strftime "%d/%m/%y"
python -m datetime datetime fromisoformat 2024-05-01T12:30:45Z
I think datetime is not primarily used as a CLI tool in workflows since tools like date (Linux/MacOS) already exist for many datetime-related tasks. If you only have access to python runtime then best is to do inline executions such as
python -c "import datetime; print(datetime.date.today().strftime('%d/%m/%y'))"
5 Likes
I would like to see more unifying direction around CLI invocations for stdlib modules.
Your proposed usage uses subcommands whose names match member names of the module. Is that suitable for a wider variety of stdlib modules? e.g., python -m threading Barrier doesn’t make any sense (to pick an example at random), but does python -m textwrap fill?
If not, I think this makes the CLIs offered by the stdlib more divergent, without any kind of vision for how I should, as a user, reader of docs, etc, learn to use the various different CLIs.
There’s been some fairly intense debate around some of the other recent CLI suggestions (re, random, etc). We can expect this one to probably get similar feedback. Individual module additions like this one are good motivation, but the thing which would be the most beneficial is some kind of notion of “what is the CLI offered by python -m ... for the stdlib?”
If we have that, filling in the blanks for datetime, tomllib, textwrap, re, and typing[1] should be easy.
2 Likes
You said well: on Linux and MacOS, not on Windows.
Mh, I doubt it will be a thing. Modules in Python are very different, having a unified way to do CLIs is impractical, IMHO.
PS: Maybe writing the class as first argument (datetime, date, time) is too verbose, but I can’t think a better alternative now.