msg60879  (view) 
Author: Steven Bethard (bethard) * 
Date: 20060309 17:37 
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{ji}{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.

msg60880  (view) 
Author: Grant Olson (logistix) 
Date: 20060310 02:42 
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

msg60881  (view) 
Author: Steven Bethard (bethard) * 
Date: 20060310 03:42 
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.

msg60882  (view) 
Author: Grant Olson (logistix) 
Date: 20060310 22:40 
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.

msg85534  (view) 
Author: Georg Brandl (georg.brandl) * 
Date: 20090405 17:32 
See also #1265100.

msg132319  (view) 
Author: Steven Bethard (bethard) * 
Date: 20110327 12:47 
The problem still exists in current trunk:
The slicing semantics have been removed from the expressions reference:
http://docs.python.org/py3k/reference/expressions.html#slicings
The datamodel and types sections still have the same equations:
http://docs.python.org/py3k/reference/datamodel.html#types
http://docs.python.org/py3k/library/stdtypes.html#typesseq
Here's a synopsis of the problem, in code:
>>> # positive step, works as described
>>> i, j, k = 2, 8, 2
>>> range(10)[i:j:k]
[2, 4, 6]
>>> [i + n * k for n in range(0, (j  i) / k)]
[2, 4, 6]
>>> [range(10)[i] for i in _]
[2, 4, 6]
>>> # negative step, does not work as described
>>> i, j, k = 10, 0, 2
>>> range(10)[i:j:k]
[9, 7, 5, 3, 1]
>>> [i + n * k for n in range(0, (j  i) / k)]
[10, 8, 6, 4, 2]
>>> [range(10)[i] for i in _]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IndexError: list index out of range
>>> # actual behavior trims 10 to 9 (is the same as 9:0:2)
>>> # that is, it trims to len(s)  1, not len(s)
>>> range(10)[9:0:2]
[9, 7, 5, 3, 1]
I propose to ignore the definition in the datamodel section, since it's talking about extended slicing in general, and doesn't mention anything about negative indices.
I propose the attached patch to fix the definition in the types section, which simply changes the statement:
If i or j is greater than len(s), use len(s)
to say:
If *i* or *j* is greater than len(s), use len(s) if *k* is positive,
or len(s)  1 if *k* is negative.

msg220778  (view) 
Author: Mark Lawrence (BreamoreBoy) * 
Date: 20140616 22:38 
The attached patch is simple enough, surely it's a simple decision as to whether or not to commit it?

msg227360  (view) 
Author: Fumihiro Bessho (bessho) 
Date: 20140923 14:26 
I also wondered the same thing today and found this issue.
I've added my comment on the patch to make the change more precise. Can anyone move it ahead and update the document?

msg282813  (view) 
Author: Martin Panter (martin.panter) * 
Date: 20161210 00:22 
Fumihiro’s suggestion seems reasonable to me (assuming it still applies to the current text)

msg282826  (view) 
Author: Martin Panter (martin.panter) * 
Date: 20161210 04:45 
Patch ruling out the len(s) corner case. I use a modified version of Fumihiro’s suggestion.

msg283927  (view) 
Author: Roundup Robot (pythondev) 
Date: 20161224 08:49 
New changeset b0b17b41edfc by Martin Panter in branch '3.5':
Issue #1446619: Account for negative slice direction in description
https://hg.python.org/cpython/rev/b0b17b41edfc
New changeset 031af2160094 by Martin Panter in branch '3.6':
Issue #1446619: Merge slicing description from 3.5
https://hg.python.org/cpython/rev/031af2160094
New changeset 4383d403aaef by Martin Panter in branch 'default':
Issue #1446619: Merge slicing description from 3.6
https://hg.python.org/cpython/rev/4383d403aaef
New changeset d63a11bd98ce by Martin Panter in branch '2.7':
Issue #1446619: Account for negative slice direction in description
https://hg.python.org/cpython/rev/d63a11bd98ce
