`python -m random --float N` should pick a float between 0 and N, not 1 and N

[andersk]

Bug report

Bug description:

In the specification for the new python -m random CLI for 3.13 (#118131), the proposed behavior was

if it's a float, print a random float between 0 and the input (via random.uniform).

However, what was actually implemented (#118132, cc @hugovk) was

$ python -m random --help
[…]
  -f, --float N         print a random floating-point number between 1 and N inclusive
$ python -m random 2.0
1.883974829952927
$ python -m random 2.0
1.034610672623156
$ python -m random 2.0
1.3676261878147473
$ python -m random 2.0
1.1875340810783404
$ python -m random 2.0
1.6148479875565644
$ python -m random 1.0
1.0

This is surprising and not helpful. Everyone will expect a range of length N starting from 0.0, not a range of length N - 1.0 starting from 1.0.

(Note that this is completely distinct from the debate about whether it’s more natural to select integers from [1, …, N] or [0, …, N - 1], as at least those are both ranges of length N.)

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

• gh-123968: Fix lower bound for python -m random --float #123971
• [3.13] gh-123968: Fix lower bound for python -m random --float (GH-123971) #124009
• gh-123968: fix -f/--float command line option description #124517
• [3.13] gh-123968: fix -f/--float command line option description (GH-124517) #124523

[hauntsaninja]

To avoid compatibility issues, it would be good to fix this in 3.13.0 so I added release-blocker. Please let me know if that's inappropriate