[Python-ideas] Exploring the 'strview' concept further

Antoine Pitrou solipsis at pitrou.net
Thu Dec 8 21:34:55 CET 2011


> But with the concrete code, I will take a stab now...
> 
> I want the ability to use a more efficient string representation when
> I know one exists -- such as when I could be using a single-byte
> charset other than Latin-1, or when the underlying data is bytes, but
> I want to treat it as text temporarily without copying the whole
> buffer.

How long is your buffer? Have you timed how long it takes to "copy" (or
decode) it?

> PyUnicode_Kind already supports the special case of
> PyUnicode_WCHAR_KIND (also known as "legacy string, not ready" --
> http://hg.python.org/cpython/file/174fbbed8747/Include/unicodeobject.h
> around line 247).  I would like to see another option for "custom
> subtype", and to accept that strings might stay in this state longer.

The unicode implementation is already complicated enough. I think adding
one further option will be a tough sell, if it doesn't exhibit major
benefits.

(note PyUnicode_WCHAR_KIND is deprecated and supposed to be removed some
day, perhaps Python 4 :-))

> I would expect bytes in particular to grow an
> as_string(encoding="Latin-1") method, which could be used to deprecate
> the various string-related methods.

Why deprecate useful functionality?

Regards

Antoine.





More information about the Python-ideas mailing list