[Python-Dev] Mini-Pep: An Empty String ABC

[Antoine Pitrou]

Raymond Hettinger <python <at> rcn.com> writes:
> Also, starting with Py3.0, strings are
> essentially abstract sequences of code points, meaning that an encode() method
> is essential to being able to usefully transform them back into concrete data.

Well, that depends:
- is a String the specification of a generic range of types which one might want
to special-case in some algorithms, e.g. flatten()
- or is a String the specification of something which is meant to be used as a
replacement of str (or, perhaps, bytes)?

If you answer the former, the String API should be very minimal and there is no
reason for it to support "encoding" or "decoding". Such a String doesn't have to
be a string of characters, it can contain arbitrary objects, e.g. DNA elements.

If you answer the latter, what use is a String subclass which isn't a drop-in
replacement for either str or bytes? Saying "hello, I'm a String" is not very
useful if you can't be used anywhere in existing code. I think most Python
coders wouldn't go out of their way to allow arbitrary String instances as
parameters for their functions, rather than objects conforming to the full str
(or, perhaps, bytes) API.


I'd like to know the use cases of a String ABC representing replacements of the
str class, though. I must admit I've never used UserString and the like, and
don't know how useful they can be. However, the docs have the following to say: 

« This UserString class from this module is available for backward compatibility
only. If you are writing code that does not need to work with versions of Python
earlier than Python 2.2, please consider subclassing directly from the built-in
str type instead of using UserString ».

So, apart from compatibility purposes, what is the point currently of *not*
directly subclassing str?

Regards

Antoine.