homepage

See attached example.
The Classic class should behave like the New-style class.

Hmm. This doesn't look like something that's easy to fix without affecting existing correct code; given 
that the behaviour has been around for a while (I'm not sure exactly how long), and that the issue is gone 
in 3.x, I suspect it may not be worth trying.
Analysis: for classic classes, the ceval loop calls PySequence_GetSlice, which corrects the negative 
indices by adding the length of the sequence (as described in the docs) and then calls the 
tp_as_sequence->sq_slice slot on the type. That ends up calling instance_slice (in 
Objects/classobject.c), which discovers that the class doesn't implement __getslice__ and so passes the 
adjusted slice on to the __getitem__ method.
I'm not sure how this could be changed to get the correct behaviour: PySequence_GetSlice would somehow 
need to know that it was going to end up calling __getitem__ rather than __getslice__.
Raymond, any thoughts?

Issue #974635 looks like the same thing. That issue was closed as a 
duplicate of issue #723806, though to my eyes #723806 doesn't look quite 
the same.

Mark,
Thank you for your analysis.
I looked at similar implementation of tp_as_sequence->sq_slice slots in
"stringobject.c" (and tuple, list).
I've added extra controls before the _PySlice_FromIndices call to let it
behave like new-style classes.
I have updated the tests.
It should be safe for 2.7, no?

Patch augmented with extensive tests:
 * Classic class or New-style class
 * with or without __getslice__

Interesting solution! While the patch itself looks fine to me, I'm not 
sure I like this solution much. It's fine to use this trick for list or 
tuple, but implementing it for all old-style classes at once seems a bit 
dangerous.
With this patch, it seems to me that the rule describing exactly what 
__getitem__ receives (for an old-style class implementing __getitem__ but 
not __getslice__) becomes rather complicated, and can no longer be deduced 
from the documentation.
I'd say leave the current behaviour as it is, and remind people that they 
should be using new-style classes wherever possible.

Closing as won't fix.

I would suggest to keep the tests, even if the bug is closed.

Okay, sounds reasonable. Reopening to consider tests.

Tests applied to trunk in r77391. Are you interested in producing a py3k version of the patch?

Here it is, with some cleaning and simple Bytes/Bytearray tests.
And Bytearray tests backported to 2.7.

Thanks! Applied in r77408.