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

Bill Mill bill.mill at gmail.com
Wed Apr 20 10:18:39 EDT 2005


On 20 Apr 2005 13:39:42 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
> 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.

Propose one, and I won't write it off without thinking, but my bias is
way against it from experience. Knowledge gets scattered across the
program, unless you're defining the start index every time you use the
list, which seems no better than adding an offset to me.

Peace
Bill Mill
bill.mill at gmail.com



More information about the Python-list mailing list