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

Raymond Hettinger 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
should be
> a
>     more specific "basereal" keeping complex out...?), but apart from
>     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
> 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
> working"
>     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 [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
>     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.

    Fry type checking dog, fry! 


More information about the Python-Dev mailing list