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