[Python-Dev] reflections on basestring -- and other abstractbasetypes

[Raymond Hettinger]

> 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
yet
>     another basetype, say "basenumber"?  Why not?  I admit that right
now
>     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
should be
> a
>     more specific "basereal" keeping complex out...?), but apart from
this
>     detail such an abstract basetype would be similarly useful (in
> practice
>     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
to
> multiply inherit from basestring AND also from another builtin type
which
> 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
payoff.


> right now the new
>     forthcoming built-in 'reverse' is trying to avoid "accidentally
> working"
>     on mappings by featuretesting for (e.g.) has_key, but if the user
>     could optionally subclass either of these abstract basetypes (but
not
>     both at once, see [6]:-), that might ease reverse's task in some
> cases.

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
operator.isMappingType
>     useful again -- right now, of course:
> >>> operator.isMappingType([])
> True
>     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...
> </donning>
> 
> Ok, ready -- fire away!

<aiming weapon="flamethrower">
    So, 1.5.2 wasn't good enough for you.
    Perhaps *this* change will be to your liking.
</aiming>

<firing> 
    Fry type checking dog, fry! 
</firing>


Raymond