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

[Aaron Bingham]

Bernhard Herzog <bh@intevation. de> writes:

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

Thanks for the excellent link!

--
--------------------------------------------------------------------
Aaron Bingham
Software Engineer
Cenix BioScience GmbH
--------------------------------------------------------------------

[Torsten Bronger]

Hallöchen!

Bernhard Herzog <bh@intevation. de> writes:

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

I see only one argument there: "Inclusion of the upper bound would
then force the latter to be unnatural by the time the sequence has
shrunk to the empty one." While this surely is unaesthetical, I
don't think that one should optimise syntax according to this very
special case. Besides, no language I know of has probems with
negative values.

Well, and the argument for "0" derives from that, according to
Dijkstra.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Peter Hansen]

Terry Hancock wrote:

However, I used to make "off by one" errors all the time in both C and Fortran,
whereas I hardly ever make them in Python.
This should probably be the overriding concern in this
case.

I can't remember the last time I made an off-by-one error
in Python (or, really, whether I ever have), whereas I
can't remember the last C program I wrote which didn't have
one.
So I like Python's slicing because it "bites *less*" than intervals in C or Fortran.

+1 QOTW

[Bernhard Herzog]

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

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

I see only one argument there: "Inclusion of the upper bound would
then force the latter to be unnatural by the time the sequence has
shrunk to the empty one." While this surely is unaesthetical, I
don't think that one should optimise syntax according to this very
special case.

The other main argument for startig at 0 is that if you do not include
the upper bound and start at 1 then the indices i of a sequence of N
values are 1 <= i < N + 1 which is not as nice as 0 <= i < N.
opportunity for an off by one error.

Then there's also that, starting at 0, "an element's ordinal (subscript)
equals the number of elements preceding it in the sequence."
Bernhard

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

[Torsten Bronger]

Hallöchen!

Bernhard Herzog <bh@intevation. de> writes:

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

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
I see only one argument there: "Inclusion of the upper bound
would then force the latter to be unnatural by the time the
sequence has shrunk to the empty one." [...]

The other main argument for startig at 0 is that if you do not
include the upper bound and start at 1 then the indices i of a
sequence of N values are 1 <= i < N + 1 which is not as nice as 0
<= i < N. opportunity for an off by one error.

The alternative is starting with 1 and using "lower <= i <= upper".
(Dijkstra's second choice.)
Then there's also that, starting at 0, "an element's ordinal
(subscript) equals the number of elements preceding it in the
sequence."

Granted, but you trade such elegancies for other uglinesses. A
couple of times I changed the lower limit of some data structure
from 0 to 1 or vice versa, and ended up exchanging a "+1" here for a
"-1" there.

It's a matter of what you are accustomed to, I suspect. We
(programmers) think with the 0-notation, but non-spoiled minds
probably not.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Roy Smith]

Terry Hancock wrote:

I used to make "off by one" errors all the time in both C and Fortran,
whereas I hardly ever make them in Python.

Part of the reason may be that most loops over lists involve
iterators, where the details of the index limits are hidden. In
Python, you write:

for item in myList:
blah

but in C and Fortran you would write:

for (i = 0; i < MAXLIST; ++i) {
blah;

do 10 i = 1, MAXLIST
10 blah

both endpoints are mentioned explicitly. C++/STL also uses iterators,
but the syntax is repulsive.

[James Stroud]

On Tuesday 19 April 2005 10:58 pm, se******@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?? ?

Here you go, no remembering "+1" or "-1". Also, see the hundreds of other
times this topic has graced this list.

i = 4
str = "asdfjkl;"
print str[:i]+str[i:]

asdfjkl;

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

[James Carroll]

If you have five elements, numbered 0,1,2,3,4 and you ask for the
elements starting with the first one, and so on for the length you
would have [0:length]. So [0:5] gives you elemets 0,1,2,3,4. Think
of the weirdess if you had to ask for [0:length-1] to get length
elements...

One based 1... n are what I call _counting numbers_
Zero based 0... n-1 are the _indexes_ (offsets) into the collection.
The first element is at offset 0.

It is a little weired that slicing does [index: count] instead of
[index:index] or [count:count] I agree, but python really does just
flow wonderfully once you see how clean code is that's written [index:
count].

In C++ the STL also has the idea that there's an 'end()' iterator that
is really one element past the end of your container. It makes things
flow really well there too. All code interates up to but not
including the last element you specify. always.

-Jim

On 19 Apr 2005 22:58:49 -0700, 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).

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

--
http://mail.python.org/mailman/listinfo/python-list

[James Stroud]

I like this, it works for any integer.

str="asdfjkl;"
i=-400
print str[:i]+str[i:] asdfjkl; i = 65534214
print str[:i]+str[i:]

asdfjkl;
Please forgive my reassigning str. I am one of those type first think later
programmers.

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

[Javier Bezos]

<se******@spawa r.navy.mil> escribió en el mensaje
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

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

Recently there was a short (sub)thread about that.
One of my messages (against half-open slices) is,
for example

http://groups-beta.google.com/group/...32dd50b57853b1

Javier

_______________ _______________ _______________ ______________
Javier Bezos | TeX y tipografía
jbezos at wanadoo dot es | http://perso.wanadoo.es/jbezos
............... ..............| ............... ............... .
CervanTeX (Spanish TUG) | http://www.cervantex.org