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

[Josiah Carlson]

Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Josiah Carlson wrote:
> > If one wants a view of text, one needs to manually
> > construct the view via 'view = textview(st, start, stop)' or some
> > equivalent spelling.  After that, any operations on a view returns views
> 
> Given Guido's sensitivity about potential misuses of
> views, it might be better if operations on views
> *didn't* return views, so that you would have to be
> explicit about creating views at all stages.

If every operation on a view returned a string copy, then what would be
the point of the view in the first place?  An alias for Python 2.x
buffer()?  No, that would be silly.

As I see it, the point of string/text views is:
1. Remove all start, stop optional arguments from all string methods,
replacing them with view slicing; resulting in generally improved call
performance by the second or third operation on the original string.
2. Reduce memory use and fragmentation of common operations (like...
while rest: prev, found, rest = rest.partition(sep) ) by performing
those operations on views.
3. Reduce execution time of slicing or slicing-like operations by
performing them on views (prev, found, rest = rest.partition(sep)).

Note that with 2 and 3, it doesn't matter how much or little you 'slice'
from the view, the slicing and/or creation of new views referencing the
original string is a constant time operation every time.

By making view.oper() always return strings instead of views, it makes
#1 the only reason for views, even though #2 and #3 are also important
and valid motivators.

I would also like to point out that it would make the oft-cited
partition example "while rest: first, found, rest = rest.partition(sep)"
run in linear rather than quadratic time, where users will be pleasantly
surprised about improvement in speed (or the lack of a reduction in
speed).


 - Josiah