[Python-Dev] UserString

[Guido van Rossum]

> >> 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).
> 
> I think all this just reinforces the notion that LBYL is
> a bad idea!

In this case, perhaps; but in general? (And I think there's a
legitimate desire to sometimes special-case string-like things, e.g.
consider a function that takes either a stream or a filename
argument.)

Anyway, can you explain why LBYL is bad?

> > 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.
> 
> Yes, this characteristic of strings is unfortunate because it
> tends to make some degree of LBYLing unavoidable. I don't
> think the right solution is to try to come up with safe ways
> of doing LBYL on strings, though, at least not in the long
> term.
> 
> Maybe in Python 3000 this could be fixed by making strings *not*
> be sequences. They would be sliceable, but *not* indexable or
> iterable. If you wanted to iterate over their chars, you
> would have to say 'for c in s.chars()' or something.
> 
> Then you would be able to test whether something is sequence-like
> by the presence of __getitem__ or __iter__ methods, without
> getting tripped up by strings.

There would be other ways to get out of this dilemma; we could
introduce a char type, for example. Also, strings might be
recognizable by other means, e.g. the presence of a lower() method or
some other characteristic method that doesn't apply to sequence in
general.

(To Alex: leaving transform() out of the string interface seems to me
the simplest solution.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)