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

Antoon Pardon apardon at forel.vub.ac.be
Thu Apr 21 06:48:18 EDT 2005


Op 2005-04-21, Steve Holden schreef <steve at holdenweb.com>:
> beliavsky at aol.com wrote:
>> Terry Hancock wrote:
>> 
>> <snip>
>> 
>>>So I like Python's slicing because it "bites *less*" than intervals
>> 
>> in C or Fortran.
>> 
>> I disagree. Programming languages should not needlessly surprise
>> people, and a newbie to Python probably expects that x[1:3] =
>> [x[1],x[2],x[3]] . Array-oriented languages, such as Fortran 90/95,
>> Matlab/Octave/Scilab, and S-Plus/R do not follow the Python convention,
>> and I don't know of Fortran or R programmers who complain (don't follow
>> Matlab enough to say). There are Python programmers, such as the OP and
>> me, who don't like the Python convention. What languages besides Python
>> use the Python slicing convention?
>> 
> The principle of least surprise is all very well, but "needless surprise 
> of newbies" is a dangerous criterion to adopt for programming language 
> design and following it consistently would lead to a mess like Visual 
> Basic, which grew by accretion until Microsoft realized it was no longer 
> tenable and broke backward compatibility.

>> Along the same lines, I think the REQUIREMENT that x[0] rather than
>> x[1] be the first element of list x is a mistake. At least the
>> programmer should have a choice, as in Fortran or VBA. In C starting at
>> 0 may be justified because of the connection between array subscripting
>> and pointer arithmetic, but Python is a higher-level language where
>> such considerations are less relevant.
>> 
> But Pythonicity required that there should be one obvious way to do 
> something. How obvious is having two ways?

How obvious is that lists can be any length? Do you consider it
an unbounded number of ways, that lists can be any length?

Like users have a choice in how long they make a list, they
should have a choice where the indexes start. (And that
shouldn't be limited to 0 and 1).

> Then when you read code you 
> would continually be asking yourself "is this a one-based or a 
> zero-based structure?", which is not a profitable use of time.

No you wouldn't. If you have the choice you just take the start
index that is more natural. Sometimes that is 0 sometimes that
is 1 and other times it is some whole other number. The times
I had the opportunity to use such structures, the question of
whether it was zero-based or one-based, rarely popped up.
Either it was irrelevant or it was clear from what you were
processing.

That you are forced to use zero-based structures, while the
problem space you are working on uses one-based structures
is a far bigger stumbling block where you continually have
to be aware that the indexes in your program are one off
from the indexes the problem is expressed in.

The one obvious way is to use the same index scheme as the
one that is used in the specification or problem setting.
Not to use always zero no matter what.

-- 
Antoon Pardon



More information about the Python-list mailing list