[Python-3000] Making more effective use of slice objects in Py3k
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
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
> 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:"
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.
More information about the Python-3000