On 2010-10-04, at 05:04 , Eviatar Bach wrote:
Hello,
I have a proposal of making the range() function inclusive; that is, range(3) would generate 0, 1, 2, and 3, as opposed to 0, 1, and 2. Not only is it more intuitive, it also seems to be used often, with coders often writing range(0, example+1) to get the intended result. It would be easy to implement, and though significant, is not any more drastic than changing print to a function in Python 3. Of course, if this were done, slicing behaviour would have to be adjusted accordingly.
What are your thoughts?
Same as the others: 0. This is a discussion for python-ideas, I'm CCing that list 1. This is a major backwards compatibility breakage, and one which is entirely silent (`print` from keyword to function wasn't) 2. It loses not only well-known behavior but interesting properties as well (`range(n)` has exactly `n` elements. With your proposal, it has ``n+1`` breaking ``for i in range(5)`` to iterate 5 times as well as ``for i in range(len(collection))`` for cases where e.g. ``enumerate`` is not good enough or too slow) 3. As well as the relation between range and slices 4. I fail to see how it is more intuitive (let alone more practical, see previous points) 5. If you want an inclusive range, I'd recommend proposing a flag on `range` (e.g. ``inclusive=True``) rather than such a drastic breakage of ``range``'s behavior. That, at least, might have a chance. Changing the existing default behavior of range most definitely doesn't. I'd be −1 on your proposal, −0 on adding a flag to ``range`` (I can't recall the half-open ``range`` having bothered me recently, if ever)