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?
 

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.

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).

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.