Title: default index for __getslice__ is not sys.maxint
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, drochner, georg.brandl, georg.brandl
Priority: normal Keywords:

Created on 2004-03-02 17:41 by drochner, last changed 2008-03-22 08:13 by georg.brandl. This issue is now closed.

Messages (4)
msg60473 - (view) Author: Matthias Drochner (drochner) Date: 2004-03-02 17:41
(This applies also to __setslice__ and possibly more.)
(This was already present in Python-2.2.)

If the upper slice index is omitted, a default is
passed to the __getslice__ method.
Documentation claims this is sys.maxint.
This is wrong if INT_MAX and LONG_MAX differ; what
is passed is INT_MAX while sys.maxint is LONG_MAX.

I'm not sure whether to call it a code bug or a
documentation bug; at least there is code out there
which compares to sys.maxint.

The whole code path from ceval.c:_PyEval_SliceIndex()
to operator.c:op_getslice() to 
abstract.c:PySequence_GetSlice() to
classobject.c:instance_slice() has just room for
an "int", so a code fix is pretty invasive...

A small test program to check this:
import sys

class sl(object):
        def __getslice__(self, a, b):
                return (a, b)

print "sys.maxint = %ld" % sys.maxint
bounds = sl()[:]
print "default bounds = [%ld, %ld]" % bounds
gives on NetBSD/amd64:
sys.maxint = 9223372036854775807
default bounds = [0, 2147483647]

msg60474 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2006-01-10 22:20
Logged In: YES 

Do we want to support long slice indices?
msg64302 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-22 00:37
This has been fixed around r42454.
msg64316 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-03-22 08:13
Closing as Fixed.
Date User Action Args
2008-03-22 08:13:05georg.brandlsetstatus: open -> closed
nosy: + georg.brandl
resolution: fixed
messages: + msg64316
2008-03-22 00:37:13belopolskysetnosy: + belopolsky
messages: + msg64302
2004-03-02 17:41:13drochnercreate