[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:
> 
> > Up until this morning I was planning on writing everything such that
> > constructive manipulation (upper(), __add__, etc.) returned views of
> > strings.
> 
> I was about to say that this would be completely pointless,
> when I realised the point is so that further operations on
> these results would return views of them. In Josiah's
> views-always-return-views world, that would actually make
> sense -- but only if we really wanted such a world.

Code wise, it could easily be a keyword argument on construction.


> To my mind, the use of views is to temporarily call out
> a part of a string for the purpose of applying some
> other operation to it. Views will therefore be
> short-lived objects that you won't want to keep and
> pass around. I suspect that, if views are the default
> result of anything done to a view, one will almost
> always be doing a str() on the result to turn it back
> into a non-view. If that's the case, then returning
> views would be the wrong default.

If views are always returned, then we can perform some optimizations
(adjacent view concatenation, etc.), which may reduce running time,
memory use, etc.  If the user *needs* a string to be returned, they can
always perform str(view).  But remember, since 2.x strings are going
away in 3.x, then it would really be bytes(view).  I've looked through
the methods available to them, and I'm happy that views are gaining
traction, if only so that I can get view(bytes).partition() .

If we always return strings (or bytes in 3.x), then all of those
optimizations are lost.  I'm writing them with optimizations, but they
can certainly be removed later.

Oh, and I've only got about 15 methods of the 60+ left to implement.


 - Josiah