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

Guido van Rossum guido at python.org
Tue Aug 29 19:31:49 CEST 2006

On 8/29/06, Josiah Carlson <jcarlson at uci.edu> wrote:

"Guido van Rossum" <guido at python.org> wrote: > On 8/28/06, Josiah Carlson <jcarlson at uci.edu> wrote: > > While there are examples where views can be slower, this is no different > > than the cases where deque is slower than list; sometimes some data > > structures are more applicable to the problem than others. As we have > > given users the choice to use a structure that has been optimized for > > certain behaviors (set and deque being primary examples), this is just > > another structure that offers improved performance for some operations. > > As long as it is very carefully presented as such I have much less of > a problem with it. > > Earlier proposals were implying that all string ops should return > views whenever possibe. That, I believe, is never going to fly, and > that's where my main objection lies. String operations always returning views would be arguably insane. I hope no one was recommending it (I certainly wasn't, but if my words were confusing on that part, I apologize); strings are strings, and views should only be constructed explicitly.

I don't know about you, but others have definitely been arguing for that passionately in the past.

After you have a view, I'm of the opinion that view operations should return views, except in the case where you explicitly ask for a string via str(view).

I think it's a mixed bag, and depends on the semantics of the operation.

For operations that are guaranteed to return a substring (like slicing or partition() -- are there even others?) I think views should return views (on the original buffer, never views on views).

For operations that may be forced to return a new string (e.g. concatenation) I think the return value should always be a new string, even if it could be optimized. So for example if v is a view and s is a string, v+s should always return a new string, even if s is empty.

BTW beware that in py3k, strings (which will always be unicode strings) won't support the buffer API -- bytes objects will. Would you want views on strings or ob bytes or on both?

> Having views in a library module alleviates many of my objections. > While I still worry that it will be overused, deque doesn't seem to be > overused, so perhaps I should relax.

While it would be interesting (as a social experiment) for views to be in the builtins module (to test abuse theories), it is probably much better for it to sit in the collections module.

I'm still very strong on having only a small number of data types truly built-in; too much choice is much more likely to encourage the wrong choice, or reduced maintainability.

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

More information about the Python-3000 mailing list