aleax at aleax.it
Sun Feb 20 17:41:31 CET 2005
On 2005 Feb 20, at 17:06, Guido van Rossum wrote:
>> 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"
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.
> 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.
More information about the Python-Dev