[Python-Dev] Mini-Pep: An Empty String ABC (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Sun Jun 1 13:42:58 CEST 2008

Raymond Hettinger <python 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:

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.

More information about the Python-Dev mailing list