Why Python does *SLICING* the way it does??

[Antoon Pardon]

Op 2005-04-20, Bill Mill schreef <bill.mill at gmail.com>:
> On 20 Apr 2005 12:52:19 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>> Op 2005-04-20, Torsten Bronger schreef <bronger at physik.rwth-aachen.de>:
>> > Hallöchen!
>> >
>> > nde at no.spam.org (Nick Efford) writes:
>> >
>> >> seberino at spawar.navy.mil <seberino at spawar.navy.mil> wrote:
>> >>> Many people I know ask why Python does slicing the way it does.....
>> >>
>> >>> Can anyone /please/ give me a good defense/justification???
>> >>
>> >>> I'm referring to why mystring[:4] gives me elements 0, 1, 2 and 3
>> >>> but *NOT* mystring[4] (5th element).
>> >>
>> >> mystring[:4] can be read as "the first four characters of
>> >> mystring".  If it included mystring[4], you'd have to read it as
>> >> "the first five characters of mystring", which wouldn't match the
>> >> appearance of '4' in the slice.
>> >>
>> >> [...]
>> >>
>> >> It all makes perfect sense when you look at it this way!
>> >
>> > Well, also in my experience every variant has its warts.  You'll
>> > never avoid the "i+1" or "i-1" expressions in your indices or loops
>> > (or your mind ;).
>> >
>> > It's interesting to muse about a language that starts at "1" for all
>> > arrays and strings, as some more or less obsolete languages do.  I
>> > think this is more intuitive, since most people (including
>> > mathematicians) start counting at "1".  The reason for starting at
>> > "0" is easier memory address calculation, so nothing for really high
>> > level languages.
>> 
>> Personnaly I would like to have the choice. Sometimes I prefer to
>> start at 0, sometimes at 1 and other times at -13 or +7.
>> 
>
> -1. You can start arrays at 0 or 1 (and arbitrary bases? I don't
> recall) in VB, and it's an unmitigated disaster. It adds needless
> complexity.

Complexity that is now put on the programmers shoulders.

If I have a table with indexes going from -13 to +7, I have to
add the offset myself if I want to use a list for that.

> What our slicing system loses in elegance in a few cases,
> it more than makes up for in consistency throughout all programs.

You write this af if other solutions can't be consistent.

-- 
Antoon Pardon