[Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation

Travis Oliphant oliphant.travis at ieee.org
Thu Feb 9 10:08:36 CET 2006


Eric Nieuwland wrote:

> Travis Oliphant wrote:
>
>> PEP:  ###
>> Title:  Allowing any object to be used for slicing
>> [...]
>> Rationale
>>
>>    Currently integers and long integers play a special role in slice
>>    notation in that they are the only objects allowed in slice
>>    syntax. In other words, if X is an object implementing the sequence
>>    protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both
>>    integers or long integers.  There is no way for obj1 and obj2 to
>>    tell Python that they could be reasonably used as indexes into a
>>    sequence.  This is an unnecessary limitation.
>> [...]
>
>
> I like the general idea from an academic point of view.
> Just one question: could you explain what I should expect from x[ 
> slicer('spam') : slicer('eggs') ]  when slicer implements this protocol?
> Specifically, I'd like to known how you want to define the interval 
> between two objects. Or is that for the sliced/indexed object to decide?

I'm not proposing to define that.  The sequence protocol already 
provides to the object only a c-integer (currently it's int but there's 
a PEP to change it to ssize_t).   Right now, only Python integer and 
Python Long integers are allowed to be converted to this c-integer 
passed to the object that is implementing the slicing protocol.  It's up 
to the object to deal with those integers as it sees fit.

One possible complaint that is easily addressed is that the slot should 
really go into the PyNumber_Methods as nb_index because a number-like 
object is what would typically be easily convertible to a c-integer.  
Having to implement the sequence protocol (on the C-level) just to 
enable sq_index seems in-appropriate.

So, I would change the PEP to implement nb_index instead...

-Travis



More information about the Python-Dev mailing list