[Python-3000] Making more effective use of slice objects in Py3k

[Guido van Rossum]

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/)