[Python-Dev] reflections on basestring -- and other
python at rcn.com
Sun Nov 2 17:52:26 EST 2003
> 1. Shouldn't class UserString.UserString inherit from basestring?
The functionality of UserString has been subsumed by inheriting from
str. So, its main purpose now is to keep old code working which means
that it is probably not wise to suddenly convert it from a classic class
to a new-style class.
> 3. And perhaps baseinteger (and float and complex) should all subclass
> another basetype, say "basenumber"? Why not? I admit that right
> I have no use cases where I _do_ want to accept complex numbers as
> well as int, long, float, and gmpy thingies (so, maybe there
> more specific "basereal" keeping complex out...?), but apart from
> detail such an abstract basetype would be similarly useful (in
> I would use it since I do not expect complex in my apps anyway).
At one time, I also requested an abstract numeric inheritance hierarchy
with real=union(int,float,long) and numbers=union(real,complex).
However, much time has passed and the need has never risen again.
> ...does anybody see any problem if, in 2.4, we take away the ability
> multiply inherit from basestring AND also from another builtin type
> does not in turn inherit from basestring.
I would rather leave this open than introduce code to prevent it. My
sense is that blocking it would introduce complexity in coding,
documentation, understanding, and debugging while offering near zero
> right now the new
> forthcoming built-in 'reverse' is trying to avoid "accidentally
> on mappings by featuretesting for (e.g.) has_key, but if the user
> could optionally subclass either of these abstract basetypes (but
> both at once, see :-), that might ease reverse's task in some
In the C code, the actual test is for PySequence_Check() which seems to
do a good job of finding non-mapping objects implementing __getitem__.
> Why, such abstract basetypes might even make
> useful again -- right now, of course:
> >>> operator.isMappingType()
> and therefore there isn't much point in that function:-).
In the meantime, I would like to remove that function from the operator
module. It is broken.
> <donning suit="asbestos">
> ...just a sec...
> Ok, ready -- fire away!
So, 1.5.2 wasn't good enough for you.
Perhaps *this* change will be to your liking.
Fry type checking dog, fry!
More information about the Python-Dev