[Python-3000] Making more effective use of slice objects in Py3k (original) (raw)

Josiah Carlson jcarlson at uci.edu
Thu Aug 31 04:20:06 CEST 2006

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.

More information about the Python-3000 mailing list