inclusive-lower-bound, exclusive-upper-bound (was Re: Range Operation pre-PEP)

[Tim Peters]

[Andrew Maizels]
> OK, next question: why does Python start indexes at zero?

Like C (and many other languages), Python views indices as *offsets* from the
start of the sequence being indexed.  The element at the start of a sequence
is clearly at offset 0, etc.  Note that since Python is very keen to make
writing extension modules in C pleasant, it's quite a practical benefit that
they have the same view of this.

> Your example would work perfectly well if the range returned
> [1, 2, 3, 4] and the list was indexed starting with 1.  Basically,
> range(4) has to produce a list of four items, we just differ on
> what those items should be.

But sequences *are* indexed starting at 0 in Python, so having range(4)
produce [1, 2, 3, 4] *in Python* would be, well, stupid.  The decisions
aren't independent.

> I'm not just being difficult; I'm trying to design my own language,
> and this is one of the things I have different to Python.  If I've
> missed something where the Python way is superior, then I might want
> to change my mind.

You can make it work either way, although (as above) there's reason to favor
0-based indexing if ease of talking between Pixy and C is interesting to you.
Icon is a good example of a language with the same basic "indices point
*between* elements" (== "indices are offsets") approach, but where indices
start at 1.  In two respects this can be nicer:

1. The last element of a non-empty Icon list (or string) is (using
   Python spelling) list[len(list)].  In Python, at the start, the
   only way to spell it was list[len(list)-1].  That created its own
   breed of "off by 1" errors.  But Python later grew meaning for
   negative list indices too, and since then list[-1] is the best
   way to get at the last list element.

2. Spelling "the point just beyond the end of the sequence" is
   easier in Icon:  in Python that's index len(list), in Icon it's
   index 0 (or *its* breed of off-by-1 temptation, len(list)+1).
   That is, indices in the 0-based Python look like:

      x[0] x[1] x[3]
     0    1    2    3  positive flavor
    -3   -2   -1    3  negative flavor

   but in the 1-based Icon they're:

      x[1] x[2] x[3]
     1    2    3    4  positive flavor
    -3   -2   -1    0  negative flavor

   If only 1's-complement integer arithmetic had caught on, Python
   could get rid of the "3 wart" in the lower-right corner by using
   -0 instead <wink>.

> The way I have things at the moment, in Pixy (my language), array
> indexes default to start at 1, but can be declared to any range (like
> Pascal).

Or Perl or Fortran77 or any number of other languages.  The flexibility
creates its own problems, though; for example, how can I write a general
routine in Pixy to iterate over the elements of a passed-in array?  In Python
(or C, or any number of other languages), I can always start indexing at 0.
In Pascal you have to clutter the argument list by passing the array bounds
as well as the array.  In Perl, the index base is a magical global vrbl and
applies to *all* arrays, and then routines written *assuming* a particular
base (not coincidentally, usually the author's favorite base <wink>) can work
or fail depending on whether somebody else fiddled the global's value.  In
Ada there are inquiry functions to *ask* an array what its declared bounds
were; that allows writing general code without relying on globals or
cluttering argument lists, but general code is wordy due to all the
inquiries, and array objects have to allocate space to store the bounds info.

> Strings are indexed starting with 1 as well.

I should hope so.

> Is there a good reason not to do this?

If you can't think of at least three "good reasons" to do this *and* not to
do this, learn some more languages.  There are almost no pure wins or pure
losses in language design.

see-abc-for-why-a-newbie-friendly-language-is-a-bad-idea-and-c++-
    for-why-it's-a-good-one<wink>-ly y'rs  - tim