[Python-Dev] UserString

[Alex Martelli]

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