> >> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com