[Python-3000] Making more effective use of slice objects in Py3k
ncoghlan at iinet.net.au
Sun Aug 27 16:59:24 CEST 2006
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)
> or perhaps even as
> 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
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:
Contrast this with the copying version:
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
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
More information about the Python-3000