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

[Josiah Carlson]

"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.

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