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

Raymond Hettinger python at rcn.com
Mon Nov 3 03:16:06 EST 2003

> > > multiply inherit from basestring AND also from another builtin
> > 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.

> The payoff would be just in avoiding confusion.  I don't see what
> complexity there could be in making each base* abstracttype
> incompatible with the others -- guess I'm missing something...?

More rules to remember:  Thing X doesn't work with thing Y but W which
is like X never got taken care of.

More docs to read and write:  You would document that the combination is
illegal and explain why, right?

More code to implement the check for prohibited combinations.

Payoff: only when someone multiply inherits from an abstract builtin
type and another builtin type.  Does anyone other than you, me, Armin,
and Tim even use multiple inheritance?  This basically never comes up
unless we're spending an evening seeing how creating toy problems just
to push the features to the limits.

Put another way:  Is this a real world problem for anyone outside python
blackbelts who already know better?  Answer:  Probably not.

> > operator.isMappingType
>    ...
> > In the meantime, I would like to remove that function from the
> > module.  It is broken.

> Yes, but isn't isSequenceType pretty iffy too...?


>>> import operator
>>> map(operator.isSequenceType, [(), [], 'ab', u'ab', {}, 1])
[True, True, True, True, False, False]
>>> map(operator.isMappingType, [(), [], 'ab', u'ab', {}, 1])
[True, True, True, True, True, False]

The first is 100% correct.
The second has four false positives.

For user defined classes implementing __getitem__, neither function can
distinguish between a mapping or a sequence.   This is the best they can

Raymond Hettinger

More information about the Python-Dev mailing list