Title: overintelligent slice() behavior on integers
Type: Stage:
Components: Interpreter Core Versions: Python 2.2
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, rhettinger, russt
Priority: normal Keywords:

Created on 2003-04-18 18:17 by russt, last changed 2003-06-11 04:20 by rhettinger. This issue is now closed.

Messages (4)
msg15509 - (view) Author: Russ Thompson (russt) Date: 2003-04-18 18:17
slices such as a[:7] give a key of slice(0,7,None)
whereas a[:7.1] gives a key of slice(None,7.1,None)

Slices should not assume that the object indices
begin at zero, since that is actually a characteristic of 
the object.  The current behavior cripples an object that 
wants, say, to start its indices with negative numbers.

a[:7] should pass a key of slice(None,7,None).

msg15510 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2003-06-10 21:45
Logged In: YES 

How does having 'slice' not round its arguments have anything 
to do with assuming indices start at zero?
msg15511 - (view) Author: Russ Thompson (russt) Date: 2003-06-10 22:23
Logged In: YES 

'slice' doesn't round its arguments.  The difference
is whether you pass an integer or a float as part
of the slice.  Thus:
a[:7] gives a key of slice(0,7,None)
a[:7.0] gives a key of slice(None,7.0,None)

What's going on I suspect is that the python
has two different behaviours for __getitem__.
The first handles slices with integer only
components, and defaults to starting at zero.
The second handles anything else.  This is
probably done in order to accomodate old 
'list' and 'tuple' implementation code that doesn't
accept starting indices of None.  But the best
solution would be to eliminate the dual behavior
of slice and revise the list and tuple code to 
accept the more general behavior.
msg15512 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-06-11 04:20
Logged In: YES 

Russ, you're right about there being two behaviors for the 
implementation of the slice notation(see apply_slice() in 
Python/ceval.c).  This occurs in the bytecode interpreter 
rather than some object's implementation of __getitem__.

While it is unfortunate, it can't be fixed without breaking 
code which defines __getitem__ but doesn't provide a None-
to-zero converter.

Factiod of the day, interpreter doesn't just assume 0 for 
None, it clamps the values in a range of 0<= value <= 

>>> class C:
        def __getitem__(self, i):
            return i

>>> c = C()
>>> c[10000000000000000000L:]
slice(2147483647, 2147483647, None)

I recommend you close the bug as Won't Fix.
Date User Action Args
2009-02-14 13:58:37ajaksu2linkissue974635 dependencies
2003-04-18 18:17:17russtcreate