[Python-Dev] reflections on basestring -- and other
mcherm at mcherm.com
Mon Nov 3 08:55:12 EST 2003
Alex muses on basestring:
> 2. If we do want to encourage such typetest idioms, it might be a good idea
> to provide some other such abstract basetypes for the purpose.
> If there was an abstract basetype, say "baseinteger", from which int and
> long derived,
Great idea... I think there should be single type from which all built-in
integer-like types inherit, and which user-designed types can inherit
if they want to behave like integers. I think that type should be called
"int". Once the int/long distinction is completely gone, this will be
quite clean, the only confusion now is that the int/long distinction isn't
yet completely hidden.
> 4. Furthermore, providing "basenumber" would let user-coded classes "flag"
> in a simple and direct way "I'm emulating numbers".
Okay, that sounds like it might be useful, at least to those people who
work with wierd varieties of numbers. But I can't think how. Normally,
I figure that if you overload addition, multiplication, subtraction, and
perhaps a few other such operators, then you're trying to emulate numbers
(that or you're abusing operator overloading, and I have no real sympathy
for you). What use cases do you have for "basenumber" (I don't mean
examples of classes that would inherit from basenumber, I mean examples
where that inheritance would make a difference)?
> IF a user class could flag itself as "numeroid" by inheriting basenumber,
> THEN the "accidental commutativity" COULD be easily removed at least
> for such classes.
Okay, that's one use case. Any others? 'cause I'm coming up blank.
> ...does anybody see any problem if, in 2.4, we take away the ability to
> multiply inherit from basestring AND also from another builtin type which
> does not in turn inherit from basestring...?
I do! I personally wouldn't try to create the class "perlnum" which
inherits from basestring and also basenumber and which tries to magicaly
know which is desired and convert back and forth on demand. But I'm
sure *someone* out there is just dying to write such a class. Why
prevent them? Not that I'd every USE such a monstrocity, but just don't
see the ADVANTAGE in providing the programmer with a straightjacket by
typechecking them (at the language level) to prevent uses outside of
those envisioned by the language implementers. It sounds decidedly
non-pythonic to me.
-- Michael Chermside
More information about the Python-Dev