[New-bugs-announce] [issue9379] random.randrange behaviour problems
report at bugs.python.org
Sun Jul 25 21:18:53 CEST 2010
New submission from Łukasz Langa <lukasz at langa.pl>:
Two behaviour problems with random.randrange:
1. Method argument `start` behaves as `stop` if `stop` is not defined:
>>> from random import randrange
Help on method randrange in module random:
randrange(self, start, stop=None, step=1, int=<class 'int'>, default=None, maxwidth=9007199254740992) method of random.Random instance
Choose a random item from range(start, stop[, step]).
>>> randrange(10) #start=10
Clearly this is because randrange() mimicks the range() interface. Sphinx documentation specifies the behaviour clearly. The problem is, help() can mislead someone in this case.
2. `step` does not work when only `start` (acting as `stop`) specified:
>>> [randrange(0, 10, step=5) for i in range(10)]
[5, 5, 5, 0, 5, 5, 5, 0, 0, 5]
>>> [randrange(10, step=5) for i in range(10)]
[5, 2, 4, 4, 6, 2, 7, 1, 5, 7]
One would expect the latter to work the same way as the former.
Case 2 is clearly a bug that should be addressed. Raymond, Mark - would a patch for this be accepted for 2.7.x, 3.1.x and 3.2? If so I can provide one.
In Case 1 we can do one of two things (or both):
A. Tweak the docstring to specify the actual behaviour explicitly.
B. Change the function definition to: `randrange(self, limit, *args, **kwargs)`. This is backwards compatible if we'd process `args` and `kwargs` correctly to keep the current interface intact (e.g. `start` would be processed in `kwargs`). This would leave a more predictable help().
Raymond, Mark - I'd say we absolutely do A. Does any of you object about B?
components: Library (Lib)
nosy: BreamoreBoy, lukasz.langa, rhettinger
title: random.randrange behaviour problems
versions: Python 2.7, Python 3.1, Python 3.2
Python tracker <report at bugs.python.org>
More information about the New-bugs-announce