gh-161452: Fix `python -m random` with a non-positive integer input by andresdelfino · Pull Request #161453 · python/cpython

andresdelfino · 2026-11-05T22:27:30Z

When python -m random gets a single integer input, main() called randint() inside the try block that converts the input with int(). For an integer N <= 0, the ValueError that randint() raises for an empty range was taken to mean that the input is not an integer, so python -m random 0 printed 0.0 and a negative N printed a random negative float. This keeps only the conversions inside the try blocks (the randint() and uniform() calls move to else: blocks), so an integer input now behaves like --integer N, as documented.

Run from the command line, both forms now print a one-line error and exit with status 1, instead of a traceback:

$ ./python -m random -3
error: empty range in randint(1, -3)
$ ./python -m random --integer 0
error: empty range in randint(1, 0)

main() itself still raises the ValueError; only the __main__ block catches it.

The new tests check that 0 and -5 raise the same ValueError from main() with and without --integer, and that the command line reports the short error message.

🤖 Generated with Claude Code

Issue: python -m random N prints a float for an integer N <= 0 #161452

When given a single integer input, main() called randint() inside the same try block that converts the input with int(). The ValueError that randint() raises for an empty range was then taken to mean that the input is not an integer, so "python -m random 0" printed 0.0 and a negative N printed a random negative float, instead of failing like "--integer N" does. Only convert the input inside the try block. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

gvanrossum · 2026-11-06T01:01:12Z

Don't you want to move this to an (inner) else: block too?

FWIW, I think it's the right place: uniform() not raises (c.f. randint).

So, here we have only parsing failures for floats. In that case it's reasonable to try choice() as a fallback.

While Sergey is right, it would be easier to read if the same pattern is followed. Let's to think of. Let me know what you prefer.

I agree with @gvanrossum, it's better to move return uniform(0, val) to an else: block as well.

vstinner

This change is backward incompatible, but it respects the documentation: https://docs.python.org/dev/library/random.html#command-line-usage

If no options are given, the output depends on the input:
Integer: same as --integer.

Hum. Displaying a long traceback is not really user friendly. Can you catch the exception and display a (short) error message instead?

$ ./python -m random -3
Traceback (most recent call last):
  File "/home/vstinner/python/main/Lib/runpy.py", line 201, in _run_module_as_main
    return _run_code(code, main_globals, None,
                     "__main__", mod_spec)
  File "/home/vstinner/python/main/Lib/runpy.py", line 87, in _run_code
    exec(code, run_globals)
    ~~~~^^^^^^^^^^^^^^^^^^^
  File "/home/vstinner/python/main/Lib/random.py", line 1088, in <module>
    print(main())
          ~~~~^^
  File "/home/vstinner/python/main/Lib/random.py", line 1079, in main
    return randint(1, val)
  File "/home/vstinner/python/main/Lib/random.py", line 341, in randint
    raise ValueError(f"empty range in randint({a}, {b})")
ValueError: empty range in randint(1, -3)

cc @hugovk who authored this feature.

hugovk · 2026-11-06T16:52:18Z

Yes, a short error message would be better than the traceback.

Move the uniform() call to an else block too, matching the integer branch. When run from the command line, catch the ValueError for an empty integer range and exit with a one-line error message instead of a traceback. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

andresdelfino · 2026-11-07T00:52:00Z

@vstinner I applied your suggestion, handling the exception in the block that calls main. Changing the main function itself would involve more changes in the tests. Would it be better to go that way?

vstinner · 2026-11-07T01:28:26Z

Some general notes on random CLI. I'm not sure that it's worth it to change them. I just wanted to share my findings.

./python -m random single_choice always returns single_choice. I suppose that it's a deliberate behavior. It's similar to ./python -m random 1 which returns always 1 and ./python -m random --float 0 which returns always 0.0.

There is a surprising behavior when the integer is larger than sys.get_int_max_str_digits(). int() raises ValueError: Exceeds the limit (4300 digits) for integer string conversion: value has 40096 digits and so switchs to float() which returns inf:

$ ./python -m random $(python -c "print('1'*40096)")
inf

$ ./python -m random $(python -c "print('-' + '1'*40096)")
-inf

$ ./python -m random --integer $(python -c "print('1'*40096)")
usage: python -m random [-h] [-c CHOICE [CHOICE ...] | -i N | -f N] [input ...]
python -m random: error: argument -i/--integer: invalid int value: '111111111111(...)111'

$ ./python -m random --integer $(python -c "print('-' + '1'*40096)")
usage: python -m random [-h] [-c CHOICE [CHOICE ...] | -i N | -f N] [input ...]
python -m random: error: argument -i/--integer: invalid int value: '-1111111111111(...)111'

By the way, it's possible to pass special float values:

$ ./python -m random --float inf
inf

$ ./python -m random --float nan
nan

It seems like random.uniform() always return inf when the maximum is inf:

$ ./python
>>> random.uniform(0, float('inf'))
inf

Ok, maybe it can return nan if self.random() returns 0.0 which is unlikely but possible :-)

And random.uniform(0, float('nan')) always return nan.

stale

Co-authored-by: Victor Stinner <vstinner@python.org>

vstinner

LGTM. I just have a last suggestion about adding a "real" random.main() function.

vstinner · 2026-11-07T02:24:23Z

+    import sys
+    try:
+        print(main())
+    except ValueError as exc:
+        sys.exit(f"error: {exc}")


You might rename main() to _main() and wrap these lines into a new main() function. So for example, you can call the new main() function in tests instead of having to spawn a new process.

What if I do like gzip instead, and call sys.exit directly from main? So we get the benefit you mention, and follow an existing pattern (personally I always find _main/main confusing).

What I suggest is to have a main() function which does everything: parse command line arguments, compute a random value, display the random value, call sys.exit() on error:

if __name__ == '__main__': main()

I don't care too much of how main() code would look like :-)

Got it! We were talking about the same thing :) I'll implement this, as this seems to be the common way of implementing CLIs for modules.

I ended up following your previous _main suggestion, as a lots of returns + a few try blocks would be necessary for main to handle everything properly by itself.

Split the CLI logic into _main(), which returns the result, and make main() print it and exit with a short error message on failure. Test the error path in-process instead of spawning a subprocess. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

vstinner · 2026-11-08T19:58:08Z

+                    self.assertEqual(str(cm.exception),
+                                     f"empty range in randint(1, {value})")
+
+    def test_main_error_no_traceback(self):


If test_empty_integer_range_error() is modified to test directly main(), I think that this test can be simply removed.

vstinner · 2026-11-08T19:59:02Z

+instead of a traceback. :func:`!random.main` now prints the result instead
+of returning it, and exits with the error message on failure.


Since we don't document the random.main() function, I don't think that we should document when its behavior changes.

vstinner · 2026-11-08T19:59:44Z

        ]:
            random.seed(0)
-            self.assertEqual(random.main(shlex.split(command)), expected)
+            self.assertEqual(random._main(shlex.split(command)), expected)


Same here, I would prefer to test the public main() function:

Suggested change

self.assertEqual(random._main(shlex.split(command)), expected)

with support.captured_stdout() as stdout:

random.main(shlex.split(command))

self.assertEqual(stdout.getvalue().rstrip(), str(expected))

vstinner · 2026-11-08T20:00:19Z

+        for value in ["0", "-5"]:
+            for args in [[value], ["--integer", value]]:
+                with self.subTest(args=args):
+                    with self.assertRaises(ValueError) as cm:
+                        random._main(args)
+                    self.assertEqual(str(cm.exception),
+                                     f"empty range in randint(1, {value})")


I would prefer testing the public main() function, rather than testing _main() which is more an implementation detail:

Suggested change

for value in ["0", "-5"]:

for args in [[value], ["--integer", value]]:

with self.subTest(args=args):

with self.assertRaises(ValueError) as cm:

random._main(args)

self.assertEqual(str(cm.exception),

f"empty range in randint(1, {value})")

for value in ["0", "-5"]:

err_msg = f"error: empty range in randint(1, {value})"

for args in [[value], ["--integer", value]]:

with self.subTest(args=args):

with self.assertRaises(SystemExit) as cm:

random.main(args)

self.assertEqual(str(cm.exception), err_msg)

hugovk · 2026-11-08T20:17:31Z

I'm also not keen on _main + main, we don't have any other CLIs like this.

The traceback is now replaced with a short error:

❯ ./python.exe -m random -3
error: empty range in randint(1, -3)

But that doesn't mean much to me. What's a randint? Before I had a traceback pointing me to where it all came from so I could look it up.

So I suggest, let's keep:

if __name__ == '__main__':
    print(main())

Add this validation and call _randint_cli(parser, x) in place of plain randint(1, x) in the CLI:

def _randint_cli(parser, n: int) -> int:
    if n < 1:
        parser.error(f"integer must be 1 or greater, got {n}")
    return randint(1, n)

This mean we get the native argparse error, which prints usage, and also we get colour (and colour handling):

❯ ./python.exe -m random -3
usage: python.exe -m random [-h] [-c CHOICE [CHOICE ...] | -i N | -f N] [input ...]
python.exe -m random: error: integer must be 1 or greater, got -3

And _parse_args also needs to return args, parser instead of args, parser.format_help(), and the final return help_text becomes return parser.format_help().

Keep main() returning its result as before, and have the CLI reject a non-positive integer through argparse's parser.error(), so it prints the usage and a short error message and exits with status 2. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

andresdelfino · 2026-11-08T20:39:41Z

@hugovk I followed your suggestions

hugovk

Thanks!

hugovk · 2026-11-08T20:42:23Z

+        args, parser = random._parse_args(shlex.split("--choice a b c"))
        self.assertEqual(args.choice, ["a", "b", "c"])
-        self.assertStartsWith(help_text, "usage: ")
+        self.assertStartsWith(parser.format_help(), "usage: ")


We could now remove these lines, we don't need to test argparse.

Just pushed the change. Let me know if I understood you correctly.

andresdelfino requested a review from rhettinger as a code owner November 5, 2026 22:27

bedevere-app Bot added the awaiting review label Nov 5, 2026

bedevere-app Bot mentioned this pull request Nov 5, 2026

python -m random N prints a float for an integer N <= 0 #161452

Open

skirpichev previously approved these changes Nov 5, 2026

View reviewed changes

bedevere-app Bot added awaiting core review and removed awaiting review labels Nov 5, 2026

gvanrossum reviewed Nov 6, 2026

View reviewed changes

vstinner reviewed Nov 6, 2026

View reviewed changes

rhettinger removed their request for review November 6, 2026 17:06

vstinner reviewed Nov 7, 2026

View reviewed changes

Comment thread Lib/test/test_random.py Resolved

Comment thread Lib/test/test_random.py Resolved

bedevere-app Bot added awaiting review and removed awaiting core review labels Nov 7, 2026

andresdelfino and others added 2 commits November 6, 2026 23:11

Update Lib/test/test_random.py

a4053f7

Co-authored-by: Victor Stinner <vstinner@python.org>

Remove test_main_empty_integer_range

a61d062

vstinner approved these changes Nov 7, 2026

View reviewed changes

bedevere-app Bot added awaiting merge and removed awaiting review labels Nov 7, 2026

vstinner reviewed Nov 8, 2026

View reviewed changes

hugovk approved these changes Nov 8, 2026

View reviewed changes

Do not test argparse

baa1441

		instead of a traceback. :func:`!random.main` now prints the result instead
		of returning it, and exits with the error message on failure.

Conversation

andresdelfino commented Nov 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vstinner left a comment • edited by hugovk Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hugovk commented Nov 6, 2026

Uh oh!

andresdelfino commented Nov 7, 2026

Uh oh!

Uh oh!

Uh oh!

vstinner commented Nov 7, 2026

Uh oh!

vstinner left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hugovk commented Nov 8, 2026

Uh oh!

andresdelfino commented Nov 8, 2026

Uh oh!

hugovk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

andresdelfino commented Nov 5, 2026 •

edited

Loading

vstinner left a comment •

edited by hugovk

Loading