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

[Bill Mill]

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. What our slicing system loses in elegance in a few cases,
it more than makes up for in consistency throughout all programs.

Peace
Bill Mill
bill.mill at gmail.com