[Python-Dev] UserString (original) (raw)

Alex Martelli aleax at aleax.it
Sun Feb 20 17:41:31 CET 2005

On 2005 Feb 20, at 17:06, Guido van Rossum wrote:

[Alex]

I did have some issues w/UserString at a client's, but that was connected to some code doing type-checking (and was fixed by injecting basestring as a base of the client's subclass of UserString and ensuring the type-checking always used isinstance and basestring). Oh, bah. That's not what basestring was for. I can't blame you or your client, but my intention was that basestring would only be the base of the two real built-in string types (str and unicode). The reason for its existence was that some low-level built-in (or extension) operations only accept those two real string types and consequently some user code might want to validate ("look before you leap") its own arguments if those eventually ended up being passed to aforementioned low-level built-in code. My intention was always that UserString and other string-like objects would explicitly not inherit from basestring. Of course, my intention was lost, your client used basestring to mean "any string-ish object", got away with it because they weren't using any of those low-level built-ins, and you had to comply rather than explain it to them.

I would gladly have explained, if I had understood your design intent correctly at the time (whether the explanation would have done much good is another issue); but I'm afraid I didn't. Now I do (thanks for explaining!) though I'm not sure what can be done in retrospect to communicate it more widely.

The need to check "is this thingy here string-like" is sort of frequent, because strings are sequences which, when iterated on, yield sequences (strings of length 1) which, when iterated on, yield sequences ad infinitum. Strings are sequences but more often than not one wants to treat them as "scalars" instead. isinstance and basestring allow that frequently needed check so nicely, that, if they're not intended for it, they're an "attractive nuisance" legally;-).

The need to make stringlike thingies emerges both for bad reasons (e.g., I never liked that client's "string cum re" perloidism) and good ones (e.g., easing the interfacing with external frameworks that have their own stringythings, such as Qt's QtString); and checking if something is stringlike is also frequent, as per previous para.
Darn...

Sounds like a good reason to add interfaces to the language. :-)

If an interface must be usable to say "is this string-like?" it will have to be untyped, I guess, and the .translate method will be a small problem (one-argument for unicode, two-args for str, and very different argument semantics) -- don't recall offhand if there are other such nonpolymorphic methods there.

Alex

More information about the Python-Dev mailing list