Command-line interface for the `random` module

Ideas
21

In fact there are already existing packages which allow calling any class / function from the stdlib (or other modules), e.g:

python -m fire random randint 0 20
3 Likes
22

Well that’s pretty cool. I’ll be putting that to use for testing purposes.

% python3.12 -m fire statistics mean 100,120
110

The package does need to be updated. Currently, it relies on the pipes module which was removed in Python3.13.

1 Like
23

The fix has been merged but not yet released:

1 Like
24

For reference, this was from 2016 (for 3.6): hashlib command line interface · Issue #70675 · python/cpython · GitHub

Since then, @guido has expressed support for the re CLI proposal as recently as this August: Command line interface for the `re` module

And since 2016, we’ve added a number of CLIs, at least:

3.8

asyncio:

3.9

ast:

3.12

uuid:

sqlite3:

This last one proposed by @rhettinger:

To facilitate rapid experimentation with SQL queries, add a shell to run commands and display results. Attached is minimal proof-of-concept modeled loosely on the Linux sqlite3 REPL. […]

Indeed, python -m sqlite3 is useful for when you don’t have sqlite3 CLI installed.

Similarly, I find having these simple CLIs within arm’s reach for occasional use very helpful; yes, it is possible to write your own scripts or sometimes install third-party tools (which as we’ve seen above, are often non-uniformly available across operating systems), but they’re no longer at your fingertips.

3 Likes
25

I really wish you wouldn’t push for this. It isn’t necessary and it takes Python further in a direction that was never intended. The “not at your fingertips” motivation isn’t strong and is at odds will other efforts to things out of the standard distribution.

To my eyes, this seem to have gone from “I just had an idea that might be nice” and is morphing into an insistence that “we have to have this and it is wrong to say otherwise”.

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.

1 Like
26

Efforts that I, personally, disagree with - because they are contrary to Python’s “batteries included” philosophy, and to the idea of making Python easy to use for the widest possible audience (which includes many users who cannot easily access PyPI). But this is a digression, and I’d prefer it if we don’t escalate this (relatively small) feature request into a debate about the whole “large or small stdlib” question.

Hardly. It’s simply a case of more people being in favour than against. I don’t think anyone is ignoring your objections, it’s just that you’re not persuading enough people to support you, in order to change the overall consensus.

Yes, if we wanted to build a CLI toolset, then absolutely. But no-one has framed this request in terms of such a toolset. Instead, it was proposed on the basis of it being useful, and that the associated cost isn’t large enough to outweigh that usefulness. Isn’t that how every feature of Python gets assessed?

Whereas to me, it seems like a small set of useful tools, added where the benefits seemed worthwhile, that don’t try to compete with more established implementations, but which are helpful when those more established tools aren’t available (a common occurrence for me, when working on Windows-based servers and development environments that don’t allow installation of arbitrary software).

I’m curious as to why you feel that this CLI is unacceptable when you were apparently in favour of python -m sqlite3, which is an extremely limited subset of the sqlite3 command line utility, which is easily available on most platforms.

8 Likes
27

I do not have a particular comment to make, I support this nice addition

28

I agreed with Éric’s post, but it didn’t seem worth commenting on further. If you have this perspective there isn’t a lot to talk about here. I made a similar comment in the re discussion but people are more interested in designing a new thing.

I don’t think this thread is good evidence that more people are in favor of it–participation is going to be strongly tilted toward people who are in favor, and it’s from among a tiny subset of python users (those who frequent this forum in the first place).

Really I imagine few people are actively against adding something like this–in my case it’s more that I will never use it (I doubt I’d remember it exists), and if maintaining it takes even a little bit of time away from improving the parts of Python that matter to me, that’s a net loss.

But of course I don’t control anyone else’s time, and I don’t want to argue with people all day. I would guess that most people who won’t use a random CLI are in a similar boat.

29

I have recently been working on using meson (which is based on Python) as a build system both in the case of meson-python for python-flint for building Python packages and also as a replacement for autoconf in flint.

One of the things that is nice about meson is that unlike in autoconf/make you can always assume that Python exists and can be used for anything. This means that whereas traditionally an autoconf/make script would use Unixy shell one liners you can instead invoke Python like python -c print(1+1) to have something that works cross platform (i.e. also on Windows). In this scenario any CLI provided by Python is useful and provides a portable alternative to awk etc.

In this scenario Python’s CLI provides a great cross platform alternative to other non-portable CLI options but only the stdlib can be depended on.

5 Likes
30

That’s fair. But how do we determine consensus except by proposing something and then looking at the responses? That’s not intended as a rhetorical question - if there’s a better way of getting a feel for how many people support an idea, it would be worth knowing about it.

To be honest, though, the number of people supporting or objecting to a proposal isn’t the most important matter. What’s more important is the arguments presented on each side. I should probably not have framed my comment in terms of numbers, that’s my error. What I was really trying to say is that it’s not correct to characterise the discussion here as “we have to have this and it is wrong to say otherwise” - the reality is simply that the arguments against haven’t persuaded people to change their mind.

IMO, anyone’s view can be challenged, but conversely no-one can assume their views must be accepted. And personally, I prefer concrete arguments referring to actual benefits and use cases over more abstract arguments of principle. Which is not what I’ve seen presented here. And frankly, the “this isn’t the business of the stdlib” argument is particularly weak given that so many other modules have command line interfaces. I’m not claiming that “we’ve done it before” is a sufficient argument on its own, but it is enough to undermine claims that “we shouldn’t do this because it’s not a direction we want to go in”…

5 Likes
31

It’s an important question. I don’t know that there’s a good answer[1].

I think support for a change in-the-moment is an incomplete picture, though. It’s a lot easier to add things to the stdlib than to remove them, so it makes sense to be cautious about adding features that might not be fully-baked.

This is less on-topic, but I don’t think that “direction we want to go in” is well-defined for Python, and this is part of what makes this stuff hard to figure out.

  1. outside of soliciting feedback in a more structured, wide-ranging way. And that is expensive and time-consuming ↩︎

1 Like
32

IMO it’s highly subjective, and “community consensus” is the only reliable indicator we have short of asking the SC for a ruling. Realistically, like any other appeal to “what is Pythonic”, it’s IMO better treated as a tiebreaker when making a close call, rather than as a filter on what ideas are acceptable or not.

This case is particularly unclear, because it’s closely linked to the idea of “batteries included”, which has been the subject of extensive and inconclusive debate in recent times, in spite of the fact that originally it was one of the major selling points of Python. Personally, I still think that “batteries included” is an important principle, but others don’t agree.

3 Likes
33

That’s fair. But while it’s definitely of value, it doesn’t really demand python -m random - you can do the clunkier python -c 'import random; print(random.randrange(6)) to get the job done.

34

I’m a little confused by this assertion: if Meson is being used to build something, wouldn’t it generally have been listed as a build-time dependency in pyproject.toml etc.? If the build process will invoke some Python that depends on a third-party library (maybe something like python -m mytools.version_info --format=raw --source=git?), couldn’t that just also be listed as a build-time dependency?

35

Indeed you can but there is still value in providing better CLI and Python has a unique niche here that other CLI toolsets cannot fill.

To be clear though I haven’t had much use for randrange in my build scripts so far…

Most often Meson is used to build non-Python packages so there is no pyproject.toml. Rather than the classic Unixy

./configure
make
make install

you instead have

meson setup build
meson compile -C build
meson install -C build

The premise for these commands to work is that meson exists rather than bash/make.

36

Both are great ideas, IMO. They make the functionality we already have in the stdlib more accessible for shell scripting purposes and ad-hoc usage.

5 Likes