[Python-3000] Making more effective use of slice objects in Py3k (original) (raw)

Jim Jewett jimjjewett at gmail.com
Sun Aug 27 05:30:30 CEST 2006

On 8/26/06, Guido van Rossum <guido at python.org> wrote:

On 8/26/06, Jim Jewett <jimjjewett at gmail.com> wrote: > On 8/26/06, Josiah Carlson <jcarlson at uci.edu> wrote: > > Nick Coghlan <ncoghlan at iinet.net.au> wrote:

> > > There are a couple of existing workarounds for > > > this: buffer() objects, and the start/stop > > > arguments to a variety of string methods.

> > Ahh, but string views offer a significantly more > > reasonable mechanism.

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

Maybe the idea is that instead of

pos = s.find(t, pos)

we would write

pos += stringview(s)[pos:].find(t)

???

With stringviews, you wouldn't need to be reindexing from the start of the original string. The idiom would instead be a generalization of "for line in file:"

while data:
    chunk, sep, data = data.partition()

but the partition call would not need to copy the entire string; it could simply return three views.

Yes, this does risk keeping all of data alive because one chunk was saved. This might be a reasonable tradeoff to avoid the copying. If not, perhaps the gc system could be augmented to shrink bloated views during idle moments.

-jJ

More information about the Python-3000 mailing list