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

[Nick Coghlan]

Jim Jewett wrote:
> On 8/26/06, Guido van Rossum <guido at python.org> wrote:
>> On 8/26/06, Jim Jewett <jimjjewett at gmail.com> wrote:
>> > As I understand it, Nick is suggesting that slice
>> > objects be used as a sequence (not just string)
>> > view.
> 
>> I have a hard time parsing this sentence. A slice is
>> an object with three immutable attributes -- start,
>> stop, step. How does this double as a string view?
> 
> Poor wording on my part; it is (the application of a slice to a
> specific sequence) that could act as copyless view.
> 
> For example, you wanted to keep the rarely used optional arguments to
> find because of efficiency.
> 
>    s.find(prefix, start, stop)
> 
> does not copy.  If slices were less eager at copying, this could be
> rewritten as
> 
>    view=slice(start, stop, 1)
>    view(s).find(prefix)
> 
> or perhaps even as
> 
>    s[start:stop].find(prefix)
> 
> I'm not sure these look better, but they are less surprising, because
> they don't depend on optional arguments that most people have
> forgotten about.

Actually, string views have nothing to do with what I'm suggesting (although 
my comments about them in the find/rfind thread were one of the things that 
fed into this message). I'm actually proposing an *alternative* to string 
views, because they have a nasty problem with non-local effects. It is easy to 
pass or return a string view instead of an actual string, and you get 
something that runs with subtly different semantics from what you expect, but 
that isn't likely to trigger an obvious error. It also breaks the persistent 
idiom that "seq[:]" makes a copy (which is true throughout the standard 
library, even if it isn't true for external number-crunching libraries like 
NumPy).

You also potentially end up with *every* sequence type ending up with a 
"x-view" counterpart, which is horrible. OTOH, if we make the standard library 
more consistent in always using a slice or range object anytime it wants to 
pass or return (start, stop, step) information, it provides a foundation for 
someone to do their own non-copying versions.

So with my musings, the non-copying index operation in a subsection would 
still use an optional second argument:

    s.find(prefix, slice(start, stop))

Now, the ultimate extension of this idea would be to permit slice literals in 
places other than sequence indexing (similar to how Py3k is likely to permit 
Ellipsis literals outside of subscript expressions). Naturally, parentheses 
may be needed in order to disambiguate colons:

    s.find(prefix, (start:stop))

Contrast this with the copying version:

    s[start:stop].find(prefix)

If (start:stop:step) is equivalent to slice(start, stop, step), then slice 
notation can be used to create ranges: range(start:stop:step)

The idea of making slice objects callable, with the result being a view of the 
original sequence is Jim's, not mine, and I'm not that keen on it (my 
reservations about string views apply to the more general idea of sequence 
views, too).

Cheers,
Nick.

P.S. I *will* be doing a PEP to bring this discussion together, but be warned 
that it may be a week or two before I get to it.

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