Type hierarchy

[Michael Sparks]

On Friday 13 June 2003 21:05, Pedro Werneck wrote:
> > needs isinstance(o, int) or isinstance(o, long), or float... although
>
> Maybe I'm wrong, but can't you use isinstance(o, (int, long, float)), for
> instance ?
>
> And the benefits of such changes would be greater than the effort to do it
> ?

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)

However, as you note, these can all be done right now however:
>>> numeric=(int,long,float,complex)
>>> mutable=(dict,list)
>>> collection=(tuple,dict,list)
>>> o, p, q = 1j, "hello", (1,2,3)
>>> isinstance(o,numeric)
True
>>> isinstance(p,mutable)
False
>>> isinstance(q,collection)
True

What this _doesn't_ allow however is for someone to either subclass from in
the middle of the hierarchy, or to modify the definitions of (say) numeric to
allow this:
>>> class foo(numeric): pass
>>> foo = mySpecialNumber(1,2,3)
>>> isinstance(foo, numeric)

Because numeric is immutable. However, if you're willing to accept a slight
obfuscation in order to gain the ability to add extra things inside the
hierarchy you can do this:

>>> numeric=[int,long,float,complex]
>>> mutable=[dict,list]
>>> collection=[tuple,dict,list]
>>> o, p, q = 1j, "hello", (1,2,3)
>>> isinstance(o,tuple(numeric))
True
>>> isinstance(p,tuple(mutable))
False
>>> isinstance(q,tuple(collection))
True

You could argue "fix the hierarchy", but the problem AFAICT is this: a
hierarchy forms a taxonomy - but who's taxonomy do you want? Do you want a
fixed one formed by inheritance through abstract classes, or do you want a
more flexible approach?

OP's taxonomy would map like this:

basestring = [string, unicode]
immutable = basestring + [tuple]
mutable = [list, array]
sequence = immutable+mutable
mapping = [dict]
intclasses = [int, bool]
number = intclasses+ [long, float, complex]
internal = [code, frame, traceback]

Despite these problems, if I was faced with this hierarchy I could change it
if I disagreed with it - and I do:

>>> # eg
>>> immutable = basestring + [tuple,int,long,float,complex]

ie have a flat type system makes it simpler for a user to override the
hierarchy in a way that make sense for their application. After all Russ
Salsbury disagreed, and preferred:

   Sequence = [tuple,list]
   Mapping = [dict]
   Collection = Sequence+Dict

Which is a just as valid hierarchy. The nice thing also is it makes any
hierarchy orthoganal with any other. (This is one reason I've never been 
particularly convinced of the idea of defining a single *static* hierarchy - 
multiple or single inheritance style or otherwise)

If you combined this with an appropriate metaclass type approach (or similar),
you could even update these "central" hierarchies as classes are constructed
using "class" statements :-)

This approach has problems of its own of course. Changing basestring doesn't
update sequence, etc. This could be solved by having a form of dynamic union
of subsets - akin to an SQL view added to the sets - an idea I quite like TBH.
(You could of course just have a separate class that does the same thing :-)

Just my tuppence worth :-)


Michael.