Command-line interface for the `random` module

[will_f (Will Fatherley)]

This is an exciting idea, even beyond random. On the other hand, the inclination to stick with library development is understandable.

Here’s a hygiene related thought:

With random in particular, how the CLI interacts with random._inst should be considered. For example, if there’s somehow a case in which the CLI shares runtime with another program that’s keeping careful track of its progress through random.getstate, then CLI usage may corrupt the other program’s book-keeping. Might therefore be good for CLI to either know if it should use its own random.Random instance or just use one by default. Such scenarios don’t seem common, but might include runtimes like the Docker official image or Python kernel.

[donBarbos (Semyon Moroz)]

I’m not realized why the --test flag was added.
I think it would be right to get rid of the --test flags in modules with cli.
This flag is not documented and is not displayed in the --help output.

I suggest moving the tests, but I don’t know in what form because these are performance tests and I haven’t seen the practice of calling perf test from the cli module.

Maybe this flag is useful to someone and someone uses it, please tell me

[Lucas_Malor]

I don’t understand the objections to the proposal. I think it will be very useful to have a CLI for random. CLI are also useful for who uses Python as a OS independent command line tool. Very useful for sysops and also for regular users.

I want to be more radical: i would like to see CLI also for re, datetime, math, statistics and os. But this is OT.

Anyway I didn’t know uuid has a CLI. It will save me a lot of time

[juancer (juan)]

Yes, I read part of the thread a couple of hours ago thanks to the update of @donBarbos and I was quickly impressed with the discovery. About re, @malemburg linked this thread some time ago: Command line interface for the re module

[jrivers]

The proposal has already been implemented in Python 3.13.

[donBarbos (Semyon Moroz)]

@hugovk Hi! Thank you for this feature.
As far as I know many people prefer to remove flags for self-tests (1 2 3).
But in this module the flag --test is used for performance tests, maybe you can explain why it was added and whether anyone really uses it (or maybe we have a more convenient way)

[merwok (Éric Araujo)]

The objections are cleary expressed here (I would only replace «low quality» with «varying quality»):

@rhettinger

If we want to build a CLI toolset, it needs to be a deliberate collective decision and rather than a zoo of piecemeal one-offs. Ideally, all the CLIs would be in their own directory and have a project team with a vision and some standards. To me, the current list of CLI tooling looks seems like a random collection of low quality afterthought efforts with a couple exceptions for things we really do find useful during development and testing.

[hugovk (Hugo van Kemenade)]

@donBarbos

As far as I know many people prefer to remove flags for self-tests (1 2 3).
But in this module the flag --test is used for performance tests, maybe you can explain why it was added and whether anyone really uses it (or maybe we have a more convenient way)

As I wrote in the OP:

@hugovk

Currently, python -m random generates some sample test output. We could remove this, or if we still want it, move it to python -m random --test.

As I recall, no-one commented on this point either way, so I retained the sample output like this. I don’t think it’s really needed as we have unit tests.

But I suggest we close this old topic and open a new issue or topic if you want to remove --test.