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

[Guido van Rossum]

On 8/27/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.

Which I still don't understand. (Because you give code but no
docstring or rationale, and are assuming some unspecified changes to
other things as well.)

> With the current mixed model
> (sometimes using xrange(), sometimes using slice(), sometimes using a 3-tuple,
> sometimes using separate start & stop values),

I don't recall xrange() being used anywhere except in for-loops. I
don't know of any use of 3-tuples, though the re API uses 2-tuples
consistently.

> 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,

Really? Extended slicing mostly meant adding a third "step" option to
the slice syntax, which is useful for NumPy but completely pointless
for string searches as we're discussing here. The slice() object was
invented as an API hack so that we didn't have to add new special
methods.

> 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).

It was always my intention to keep slice objects limited to NumPy apps
and the rare application of extended slicing in regular Python.

> 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

And you still haven't explained how this is going to make life easier.
I keep asking for concrete examples and you keep answering in
generalities. This is an annoying disconnect.

> 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.

What's the indices() method?

In many cases it doesn'ts eem to make a lot of sense to return a slice
object, since it doesn't convey more information than a single index
(given that the string being searched for is known -- we're not
searching regular expressions here but literal substrings).

> In addition to reducing 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.

Write the PEP and make sure it is plentiful of examples of old and new
ways of doing common string operations.

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