Mark Dickinson <dicki...@gmail.com> added the comment:

On issue 2: I agree that this is strange behavior, and would be interested to 
see a patch.  It's not 100% clear to me what the patched code should do, 
though.  In particular, an example like:

>>> randrange(10, step=5)

that mixes positional and keyword arguments is a bit odd.  It's not clear in 
this case whether the '10' should be interpreted as a 'start' argument or a 
'stop' argument:  on a 'refuse the temptation to guess' basis, I'd say that 
'randrange(10, step=5)' should be an error.

More generally, perhaps any randrange call that mixes positional and keyword 
arguments should raise an exception?

A related behaviour is:

>>> randrange(start=10)
9

This should also be an error, IMO.

Any patch should include comprehensive tests, of course.


On the first issue, yes, it would be good to clarify the docs (see the range 
docs for how this might be done).

[Ɓukasz]
> 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().

Not sure I follow this bit:  is this supposed to be a solution to problem 1 or 
problem 2?  (Or both?)  I don't really see the benefit of describing randrange 
this way in the docstring.

----------
stage:  -> needs patch

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9379>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to