[Python-Dev] Built in objects supporting slices

Guido van Rossum guido@python.org
Sun, 28 Apr 2002 18:30:22 -0400


> On Sunday 28 April 2002 15:20, Guido van Rossum wrote:
> > > At the moment, built in objects such as lists don't support the slice
> > > notaton l[a:b:c]. Would there be support for including this in Python
> 	...
> > Yes.  No PEP is needed, but I'm -0 on the idea -- I don't see what use
> > there is for this besides theoretical neatness; I'm sure it
> > complicates a lot of code.
> >
> > IOW What's the use case?
> 
> If I understood the c.l.py discussion correctly, one key issue is
> with documentation -- currently, in:
> 
> http://www.python.org/dev/doc/devel/ref/sequence-types.html
> 
> the "right" way for a contained object to support slicing is said
> to be through __getitem__ (with a slice argument), while
> __getslice__ is said to be supported only for backwards
> compatibility.  If you think __getslice__ is best, then that page
> should be edited accordingly; otherwise, built-in sequences
> should probably respect the same "right way" as others.
> 
> The only use-case I would probably use substantially is a step
> of -1 for reverse looping.  I do see in my existing code some number
> of: "for i in range(len(L)-1, 0, -1):" followed by use of L[i], and
> the like, that would be "smoother" as "for item in L[::-1]:".  Not
> a huge win, for sure, but not terrible, it would seem to me.  I see
> no such immediate application for other steps, although Python's
> standard libraries do have some cases with a step of 2 that might
> use a step-2 slice.
> 
> So, the benefits are admittedly modest, but, it seems to me, > 0.

+1 on making the built-in types accept slice objects in their
__getitem__, __setitem__, __delitem__ methods.

+0 on subsequently getting rid of their __getslice__, __setslice__,
__delslice__ methods.  PyObject_GetSlice c.s. may have to be adapted
to fall back to __getitem__ with a slice object.  The slice opcodes
may possibly be simplified.

Possible issue: I believe getslice and getitem deal differently with
negative indices (one passes them on, the other doesn't, or something
like that).  There is a bit of a rat's nest trying to keep this
compatible in all ways.

--Guido van Rossum (home page: http://www.python.org/~guido/)