[ python-Bugs-1446619 ] extended slice behavior inconsistent with docs

SourceForge.net noreply at sourceforge.net
Fri Mar 10 23:40:07 CET 2006


Bugs item #1446619, was opened at 2006-03-09 11:37
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446619&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: extended slice behavior inconsistent with docs

Initial Comment:
I don't know whether the behavior or the docs is wrong,
but the extended slice behavior does not match the
documentation.  I found three places that talk about
extended slicing:

http://docs.python.org/ref/slicings.html
The semantics for a simple slicing are as follows... It
is not an error if i or j lie outside the range of
valid indexes (such items don't exist so they aren't
selected).
The semantics for an extended slicing are as follows...

http://docs.python.org/ref/types.html
Some sequences also support ``extended slicing'' with a
third ``step'' parameter: a[i:j:k] selects all items of
a with index x where x = i + n*k, n >= 0 and i <= x < j.

http://docs.python.org/lib/typesseq.html
s[i:j:k]   slice of s from i to j with step k   (3),(5)
...
(3) If i or j is negative, the index is relative to the
end of the string: len(s) + i or len(s) + j is
substituted. But note that -0 is still 0.
(5) The slice of s from i to j with step k is defined
as the sequence of items with index x = i + n*k such
that $0 \leq n < \frac{j-i}{k}$. In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping
when j is reached (but never including j). If i or j is
greater than len(s), use len(s). If i or j are omitted
then they become ``end'' values (which end depends on
the sign of k). Note, k cannot be zero.



Given those docs, consider this behavior:

>>> range(10)[10:0:-2]
[9, 7, 5, 3, 1]

By the Sequence Type Language Reference, [10:0:-2]
selects all items with index x where x = 10 + n*(-2), n
>= 0 and 10 <= x < 0.  Since no such values of x exist,
I conclude the result should have been an empty list.

By the Sequence Type Library Reference, [10:0:-2]
selects all items with index x = 10 + n*(-2) such that
0 <= n < (0 - 10)/(-2) = 5.  Thus I conclude that I
should get indices [10, 8, 6, 4, 2].  But this is also
wrong -- that would either have given me an IndexError,
if I stick to what's written for extended slicings, or
the list [8, 6, 4, 2] if I assume that the phrase "It
is not an error if i or j lie outside the range of
valid indexes" from the simple slicings section in the
Slicings Language Reference also applies to extended
slicings.


All the references I can find document this behavior
incorrectly.  I suggest rewording all the sections to
say something like:

"""
To get the slice of s from i to j with step k, first
determine the bounds.  If k is positive, and i or j is
greater than len(s), use len(s).  If k is negative, and
i or j is greater than len(s)-1, use len(s)-1. Note, k
cannot be zero.  If i or j are omitted then they become
``end'' values (which end depends on the sign of k). 

The slice of s from i to j with step k is then defined
as the sequence of items with index x = i + n*k such
that 0 <= n < (j - i)/k.  In other words, the indices
are i, i+k, i+2*k, i+3*k and so on, stopping when j is
reached (but never including j).
"""

The most important sentence above is "If k is negative,
and i or j is greater than len(s)-1, use len(s)-1." 
Without this sentence, the documentation doesn't match
the behavior.  The remainder of the rewording is to
make it clear that the bounds are adjusted *before* the
indices are calculated.

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-03-10 16:40

Message:
Logged In: YES 
user_id=699438

You're right.  I misunderstood what you were saying.  I was
trying to point out that you wouldn't have an element '10'
but I now see that you said "indicies[10...]", not
values[10...].

Sorry.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2006-03-09 21:42

Message:
Logged In: YES 
user_id=945502

logistix wrote:
> [0,1,2,3,4,5,6,7,8,9][10]
> will return 9

Huh?  Python indexing starts from 0.  Hence:

>>> range(10)[10]
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
IndexError: list index out of range

>>> [0,1,2,3,4,5,6,7,8,9][10]
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
IndexError: list index out of range

If I didn't understand your complaint, please explain it again.

----------------------------------------------------------------------

Comment By: Grant Olson (logistix)
Date: 2006-03-09 20:42

Message:
Logged In: YES 
user_id=699438

One problem in your analysis that range(10) returns the array

[0,1,2,3,4,5,6,7,8,9]

not:

[1,2,3,4,5,6,7,8,9,10]

The 10th element of the array holds the value 9.  so when x
= 10 + (0*-2), you get 10.  Then:

[0,1,2,3,4,5,6,7,8,9][10]

will return 9

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446619&group_id=5470


More information about the Python-bugs-list mailing list