Type hierarchy

[Steven Taschuk]

Quoth Michael Sparks:
  [...]
> It strikes me that OP wants to be able to get at things in the middle of his
> type hierarchy:
>    isinstance(o,numeric))
>    isinstance(p,mutable)
>    isinstance(q,collection)

For numeric and collection, I think this would not be useful.
(More on 'mutable' below.)

There might be a little bit of shared functionality among such
types, but not much.  (Certainly int and float would not share an
implementation of __mul__, for example.)  The only other reason I
can think of to do isinstance checks is LBYL.  But then why not
just check for the existence of __add__ or __getitem__ or whatever
it is you need?  Inheritance should be for sharing implementation,
not interface.

It's different for mutable, of course, since there's no signature
which will distinguish mutable from immutable (or "amutable", if I
may coin a term, meaning "I provide no mutation facilities but do
not prevent subclasses from doing so").  I can think of cases in
which it would be helpful to know whether an object was mutable --
e.g. copy.deepcopy might be able to optimize if it could tell that
a user-defined object was immutable -- but I'm not sure a marker
interface (to borrow the Java term) is the way to go.

  [...]
-- 
Steven Taschuk                               staschuk at telusplanet.net
"What I find most baffling about that song is that it was not a hit."
                                          -- Tony Dylan Davis (CKUA)