On 8/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote: > > On 8/28/06, Josiah Carlson <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
