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

[Josiah Carlson]

Nick Coghlan <ncoghlan at iinet.net.au> wrote:
[snip]
> 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).

The copying is easily fixed.  I'm also not terribly concerned with the
persistance of views, as I expect that most people who bother to use
them (and/or care about the efficiency of str.partition, etc.) will know
what they are getting themselves into.  If they don't, then they will
post on python-[list|dev], and we can give them a link to the string
view documentation, which will explain what views are and how they can
release the references to the original object: ref = str(ref) .


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

I'm not sure your slippery-slope argument holds.  So far there are only
a few objects for which views have been proposed with any substance:
dictionaries, text and byte strings.

The removal of buffer from 3.0 does leave an opening for other
structures for which views (or even the original buffers) would make
sense, like array and mmap, but those each have implementations that
could effectively mirror the (mutable) byte string view.

As for using slices to define a mechanism for returning view-like
objects (it is effectively a different spelling), I don't particularly
care for passing around slice/xrange objects.

I would also like to mention that there exists external libraries that
offer non-copying "views" to their underlying structures, the 'array
interface' that was proposed in the last few months being a primary
example of a desired standardization of such.


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

This reduces the number of optional arguments by 1, and requires the
somewhat explicit spelling out of the slice creation (which you attempt
to remove via various syntax changes). I'm not sure these are actual
improvements to either the string (or otherwise) API, or to the general
sequence API.


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

That looks like the integer slicing PEP that was rejected.  Also, no one
has been severely restricted by syntax; one could easily write a
specialized object so that "for i in range[start:stop:step]" 'does the
right thing'.

 - Josiah