Josiah Carlson wrote: > 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() .
I know this was shot down before, but I would still like to see a "characters" type - that is, a mutable sequence of wide characters, much like the Java StringBuffer class - to go along with "bytes". From my perspective, it makes perfect sense to have an "array of character" type as well as an "array of byte" type, and since the "array of byte" is simply called "bytes", then by extension the "array of character" type would be called "characters". Of course, both the 'array' and 'list' types already give you that, but "characters" would have additional string-like methods. (However since it is mutable, it would not be capable of producing views.) The 'characters' data type would be particularly optimized for character-at-a-time operations, i.e. building up a string one character at a time. An example use would be processing escape sequences in strings, where you are transforming the escaped string into its non-escaped equivalent. -- Talin _______________________________________________ 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
