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

Guido van Rossum guido at python.org
Sun Aug 27 05:00:05 CEST 2006


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. Neither of these is > > particular convenient to work with, and buffer() is > > slated to go away in Py3k. > 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?

> string = stringview(string) > ... We can toss all of the optional start, stop > arguments to all string functions, and replace them > with either of the following: > result = stringview(string, start=None, stop=None).method(args)

> string = stringview(string) > result = string[start:stop].method(args) Under Nick's proposal, I believe we could replace it with just the final line.

I still don't see the transformation of clumsy to elegant. Please give me a complete, specific example instead of a generic code snippet. (Also, please don't use 'string' as a variable name. There's a module by that name that I can't get out of my head.)

Maybe the idea is that instead of

pos = s.find(t, pos)

we would write

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

???

And how is that easier on the eyes? (And note the need to use += because the sliced view renumbers the positions in the original string.)

result = string[start:stop].method(args)

though there is a chance that (when you want to avoid copying) he is suggesting explicit slice objects such as view=slice(start, stop) result = view(string).method(args)

-- --Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-3000 mailing list