[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.
Sounds like a good reason to add interfaces to the language. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4