[Python-ideas] Inclusive Range

[Nick Coghlan]

On the more general topic of *teaching* 0-based indexing, the best
explanation I've seen is the one where 1-based indexing is explained
as referring directly to the items in the sequence, while 0-based
indexing numbers the implicit gaps between items and then returns the
item immediately after the identified gap. Slicing for 0-based
indexing can then be explained without needing to talk about half-open
ranges at all - you just grab everything between the two identified
gaps*.

I think the main point here is that these are not independent design
decisions - the behaviour of range() (or its equivalent), indexing,
slicing, enumeration and anything else related to sequences all comes
back to a single fundamental design choice of 1-based vs 0-based
indexing. Once you make that initial decision (regardless of the
merits either way), other decisions are going to flow from it as
consequences, and it isn't really something a language can ever
practically tinker with.

Cheers,
Nick.

*(unfortunately, it's a bit trickier to mesh that otherwise clear and
concise explanation cleanly with Python's definition of ranges and
slicing with negative step values, since those offset everything by
one, such that "list(reversed(range(1, 5, 1])) == list(range(4, 0,
-1])". If I was going to ask for a change to anything in Python's
indexing semantics, it would be for negative step values to create
ranges that were half-open at the beginning rather than the end, such
that reversing a slice just involved swapping the start value with the
stop value and negating the step value. As it is, you also have to
subtract one from both the start and stop value to get the original
range of values back. However, just like the idea of ranges starting
from 1 rather than 0, the idea of negative slices giving ranges
half-open at the start rather than the end is also doomed by
significant problems with backwards compatibility. For a new language,
you might be able to make the argument that the alternative behaviour
is a better design choice. For an existing one like Python, any
possible benefits are so nebulous as to not be worth the inevitable
hassle involved in changing the semantics)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia