"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. 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). > 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. > > > Then I ask you to make it so that string views are 99.999% > > > indistinguishable from strings -- they have all the same methods, are > > > usable everywhere else, etc. > > > > For reference, I'm about 2 hours into it (including re-reading the > > documentation for Pyrex), and I've got [r]partition, [r]find, [r]index, > > [r|l]strip. I don't see significant difficulty implementing all other > > methods on views. > > > > Astute readers of the original implementation will note that I never > > check that the argument being passed in is a string; I use the buffer > > interface, so anything offering the buffer interface can be seen as a > > read-only view with string methods attached. Expect a full > > implementation later this week. > > Good luck! Thank you! - Josiah _______________________________________________ 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
