[Python-3000] Making more effective use of slice objects in Py3k

[Nick Coghlan]

Guido van Rossum wrote:
> Can you explain in a sentence or two how these changes would be
> *used*? Your code examples don't speak for themselves (maybe because
> It's Saturday morning :-). Short examples of something clumsy and/or
> slow that we'd have to write today compared to something fast and
> elegant that we could write after the change woulde be quite helpful.
> The exact inheritance relationship between slice and [x]range seems a
> fairly uninteresting details in comparison.

A more unified model for representing sequence slices makes it practical to 
offer a non-copying string partitioning method like the version of 
partition_indices() in my initial message. With the current mixed model 
(sometimes using xrange(), sometimes using slice(), sometimes using a 3-tuple, 
sometimes using separate start & stop values), there is no point in offering 
such a method, as it would be terribly inconvenient to work with regardless of 
what kind of objects it returned to indicate the 3 portions of the original 
string:

  - 3-tuples and xrange() objects can't be used to slice a sequence
  - 3-tuples and slice() objects can't be usefully tested for truth
  - none of them can be passed as optional string method arguments

I believe the current mixed model is actually an artifact of the transition 
from simple slicing to extended slicing, albeit one that is significantly less 
obvious than the deprecated __*slice__ family of special methods. Old style 
slicing and string methods use separate start and stop values. Extended 
slicing uses slice objects with start,stop,step attributes (which can be 
anything, including None). The indices() method of slice objects uses a 
start,stop,step 3-tuple. Iteration uses either a list of indices (from 
range()) or xrange objects with start,stop,step attributes (which must be 
integers).

The basic proposal I am making is to reduce this to exactly two concepts:
   - slice objects, which have arbitrary start, stop, step attributes
   - range objects, which have indices as start, stop, step attributes, behave 
like an immutable sequence, and are a subclass of slice

All other instances in the core and standard library which use a different 
representation of a sequence slice (like the optional arguments to string 
methods, or the result of the indices() method) would change to use one of 
those two types. The methods of the types would be driven by the needs of the 
standard library.

In addition to reuding the number of concepts to be dealt with from 4 to 2, I 
believe this would make it much easier to write memory efficient code without 
having to duplicate entire objects with non-copying versions.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org