1. Even though you can construct slice objects in Python using slice(left,right), you can't really do anything with them; at least not on the standard types (Numeric's arrays work with them just fine).

Couldn't we add some functionality which makes them compatible to lists and tuples (and perhaps even in a generic way for other sequences using PySequence_GetItem()) too ?

I thinking of extending the __getitem__ hook to accept slice objects. You could then maintain slices to an object in say a list and apply them to the underlying text as needed, e.g.

s = slice(1,4) l = range(10) l[s] == [1, 2, 3]

I agree that this would be nice to have. I won't have time for it before 2.2 is out, but if you want to give it a crack, I might accept it.

2. Looking through the code for '==' the optimization for 'a == a' seems too far down the call stack. Since interning strings makes this case rather common, I'd suggest to lift the optimization into the ceval loop (right along side with the INT op INT optimization).

I would agree, except there's also the point of view that since types can override __eq__ to always return false, this optimization should not be done in a way that prevents __eq__ from overriding it. --Guido van Rossum (home page: http://www.python.org/~guido/)

1. Even though you can construct slice objects in Python using slice(left,right), you can't really do anything with them; at least not on the standard types (Numeric's arrays work with them just fine).

Couldn't we add some functionality which makes them compatible to lists and tuples (and perhaps even in a generic way for other sequences using PySequence_GetItem()) too ?

I thinking of extending the __getitem__ hook to accept slice objects. You could then maintain slices to an object in say a list and apply them to the underlying text as needed, e.g.

s = slice(1,4) l = range(10) l[s] == [1, 2, 3]

I agree that this would be nice to have. I won't have time for it before 2.2 is out, but if you want to give it a crack, I might accept it.

2. Looking through the code for '==' the optimization for 'a == a' seems too far down the call stack. Since interning strings makes this case rather common, I'd suggest to lift the optimization into the ceval loop (right along side with the INT op INT optimization).

I would agree, except there's also the point of view that since types can override __eq__ to always return false, this optimization should not be done in a way that prevents __eq__ from overriding it. --Guido van Rossum (home page: http://www.python.org/~guido/)