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

[seberino]

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).

Many people don't like idea that 5th element is not invited.

(BTW, yes I'm aware of the explanation where slicing
is shown to involve slices _between_ elements. This
doesn't explain why this is *best* way to do it.)

Chris

[Bill Mill]

On 20 Apr 2005 12:52:19 GMT, Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

Op 2005-04-20, Torsten Bronger schreef <br*****@physik .rwth-aachen.de>:

Hallöchen!

nd*@no.spam.org (Nick Efford) writes:

se******@spawar .navy.mil <se******@spawa r.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

[beliavsky]

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?

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.

[Roy Smith]

Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

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.

Argggh. Having two (or more!) ways to do it, would mean that every time I
read somebody else's code, I would have to figure out which flavor they are
using before I could understand what their code meant. That would be evil.

What would actually be cool is if Python were to support the normal math
notation for open or closed intervals. Any of the following would make
sense:

foo = bar (1, 2)
foo = bar (1, 2]
foo = bar [1, 2)
foo = bar [1, 2]

That would certainly solve this particular problem, but the cost to the
rest of the language syntax would be rather high :-)

[Antoon Pardon]

Op 2005-04-20, Bill Mill schreef <bi*******@gmai l.com>:

On 20 Apr 2005 12:52:19 GMT, Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

Op 2005-04-20, Torsten Bronger schreef <br*****@physik .rwth-aachen.de>:

> Hallöchen!
>
> nd*@no.spam.org (Nick Efford) writes:
>
>> se******@spawar .navy.mil <se******@spawa r.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

[Antoon Pardon]

Op 2005-04-20, Roy Smith schreef <ro*@panix.com> :

Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

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.

Argggh. Having two (or more!) ways to do it, would mean that every time I
read somebody else's code, I would have to figure out which flavor they are
using before I could understand what their code meant. That would be evil.

This is nonsens. table[i] = j, just associates value j with key i.
That is the same independend from whether the keys can start from
0 or some other value. Do you also consider it more ways because
the keys can end in different values?

--
Antoon Pardon

[Bill Mill]

On 20 Apr 2005 13:39:42 GMT, Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

Op 2005-04-20, Bill Mill schreef <bi*******@gmai l.com>:

On 20 Apr 2005 12:52:19 GMT, Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

Op 2005-04-20, Torsten Bronger schreef <br*****@physik .rwth-aachen.de>:
> Hallöchen!
>
> nd*@no.spam.org (Nick Efford) writes:
>
>> se******@spawar .navy.mil <se******@spawa r.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

[Diez B. Roggisch]

> 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.

Subclass from builtin list - and make the necessary adjustmenst yourself in
an overloaded __getitem__.

--
Regards,

Diez B. Roggisch

[Roy Smith]

Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

Op 2005-04-20, Roy Smith schreef <ro*@panix.com> :

Antoon Pardon <ap*****@forel. vub.ac.be> wrote:

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.

Argggh. Having two (or more!) ways to do it, would mean that every time I
read somebody else's code, I would have to figure out which flavor they are
using before I could understand what their code meant. That would be evil.

This is nonsens. table[i] = j, just associates value j with key i.
That is the same independend from whether the keys can start from
0 or some other value. Do you also consider it more ways because
the keys can end in different values?

There are certainly many examples where the specific value of the
first key makes no difference. A good example would be

for element in myList:
print element

On the other hand, what output does

myList = ["spam", "eggs", "bacon"]
print myList[1]

produce? In a language where some lists start with 0 and some start
with 1, I don't have enough information just by looking at the above
code.

[Terry Hancock]

On Wednesday 20 April 2005 07:52 am, Antoon Pardon wrote:

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.

Although I would classify that as a "rare use case". So, it "ought
to be possible to do it, but not necessarily easy". Which
Python obliges you on --- you can easily create a relocatable list
class that indexes and slices anyway you see fit, e.g.:

class reloc(list): .... def __init__(self, start, contents=()):
.... self.start = start
.... for item in contents:
.... self.append(ite m)
.... def __getitem__(sel f, index):
.... if isinstance(inde x, slice):
.... if (not (self.start <= index.start < self.start + len(self)) or
.... not (self.start <= index.stop < self.start + len(self))):
.... raise IndexError
.... return self.__class__. __base__.__geti tem__(self, slice(index.sta rt-self.start, index.stop-self.start, index.step))
.... else:
.... if not (self.start <= index < self.start + len(self)):
.... raise IndexError
.... return self.__class__. __base__.__geti tem__(self, index - self.start)
....
....
r = reloc(-13, ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q'])
r[0] 'n' r[-12] 'b' r[-13] 'a' r[-14] Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 14, in __getitem__
IndexError r[0] 'n' r[3] 'q' r[4] Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 14, in __getitem__
IndexError

Note that I added the IndexError to avoid the bizarre results you
get due to "negative indexing" in the list base class (now they
would change behavior at -13 instead of at 0, which is counter-
intuitive to say the least). Better to cry foul if an index out of
range is called for in this case, because it's gotta be a bug.

What do you think, should I send it to Useless Python? ;-)

Cheers,
Terry

--
Terry Hancock ( hancock at anansispacework s.com )
Anansi Spaceworks http://www.anansispaceworks.com

[Bernhard Herzog]

Torsten Bronger <br*****@physik .rwth-aachen.de> writes:

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.

There are very good reasons for half-open intervals and starting at 0
apart from memory organization. Dijkstra explained this quite well in
http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

Bernhard

--
Intevation GmbH http://intevation.de/
Skencil http://skencil.org/
Thuban http://thuban.intevation.org/