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)
