[Python-Dev] reflections on basestring -- and other abstract basetypes

[Michael Hudson]

Alex Martelli <aleaxit at yahoo.com> writes:

> 1. Shouldn't class UserString.UserString inherit from basestring?  After all,
>     basestring exists specifically in order to encourage typetests of the form
>     isinstance(x, basestring) -- wouldn't it be better if such tests could
>     also catch "user-tweaked strings" derived from UserString ... ?
>
> 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.

I'd really rather not.  I think this is a slippery slope I want to
stay right at the top of.  Doing different things depending on which
protocol a function argument happens to implement is icky, even if
it's sometimes extremely convenient.  I don't think we should make it
easier.

> 4. Furthermore, providing "basenumber" would let user-coded classes "flag"
>     in a simple and direct way "I'm emulating numbers".  This might well be
>     useful _to Python itself_...
>     Right now, I'm stuck for an answer to the bug that a user-coded class
>     which exposes __mul__ but not __rmul__ happens to support its instances
>     being multiplied by an integer on the right -- quite surprising to users!
>     The problem is that this behavior is apparently expected, though not
>     documented, when the user-coded class is trying to simulate a _sequence_
>     rather than a number.  So, I can't just take the peculiar "accidental
>     commutativity with integers only" away.
>     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.

This is just a bug, albeit a subtle and hard to fix one.

And, as a paid up member of the anti-operator-overloading-bigot camp,
I'll just say:

a) if your user coded class is so unlike a number as to not be
   multipliable by an int, why are you overloading '*'?

and

b) if Python had different operators for sequence repition and
   multiplying numbers, the relavent bug would be much easier to
   fix...

> 7. one might of course think of other perhaps-useful abstract basetypes,
>     such as e.g. basesequence or basemapping -- 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.

Well, I (unsurprisingly, given the above) think this problem again
comes from using the same notation for two different things (mappings
and sequences).

Or looking at it another way, it comes from ancient misdesigns in the
C API that it's now essential impossible to fix (that sq_item is an
intargfunc, roughly).  I don't think we should try to cover up these
misfeatures with another.

Cheers,
mwh

-- 
  The meaning of "brunch" is as yet undefined.
                                             -- Simon Booth, ucam.chat