[ python-Bugs-1328278 ] __getslice__ taking priority over __getitem__

[SourceForge.net]

Bugs item #1328278, was opened at 2005-10-16 18:22
Message generated for change (Comment added) made by stupidgeekman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&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: Python Interpreter Core
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Josh Marshall (jpmarshall)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getslice__ taking priority over __getitem__

Initial Comment:
When creating a class that uses __getitem__ to implement slicing, if 
__getattr__ is also implemented, slicing will fail. This is due to the 
(deprecated) __getslice__ method being called before __getitem__.

The attached file demonstrates this. If __getitem__ is implemented 
on its own, all is rosy. When we add __getattr__ and do not raise an 
AttributeError when __getslice__ is searched for, the slicing fails. If 
we raise this AttributeError, __getitem__ is called next.

The only other reference I could find to this bug is on the jython 
mailing list, from 2003:
http://sourceforge.net/mailarchive/forum.php?
thread_id=2350972&forum_id=5586

My question is; why is __getslice__ called before __getitem__? I 
assumed that because it is deprecated, it would be the last resort for 
a slicing.

Is this planned to be fixed, or is there existing behaviour that is 
reliant on it?
 

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

Comment By: Tim (stupidgeekman)
Date: 2007-03-14 19:33

Message:
Logged In: YES 
user_id=1743956
Originator: NO

I would suggest that the list class should use the same form suggested on
the documentation site, namely:

    if sys.version_info < (2, 0):
        # They won't be defined if version is at least 2.0 final

        def __getslice__(self, i, j):
            return self[max(0, i):max(0, j):]
        def __setslice__(self, i, j, seq):
            self[max(0, i):max(0, j):] = seq
        def __delslice__(self, i, j):
            del self[max(0, i):max(0, j):]
    ...

in order to assure that the *slice methods are not defined unless needed
for backward compatability in an older interpreter; then classes developed
with the above suggested structure should work properly.

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

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-11 11:50

Message:
Logged In: YES 
user_id=1188172

You're correct. __getslice__ is supported for backwards
compatibility, and its semantics cannot change (before 3.0,
that is).

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

Comment By: Thomas Lee (krumms)
Date: 2005-11-10 06:48

Message:
Logged In: YES 
user_id=315535

This seems to be the documented, expected behavior:

http://www.python.org/doc/2.4.2/ref/sequence-methods.html

As to _why_ __getslice__ is called before __getitem__, I'm
not sure - but it's right there in the docs.

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

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