Type hierarchy

[Andrew Dalke]

Gerrit Holl:
> But wouldn't a type hierarchy be very useful for other types as
> well? For example, checking whether something is a number, currently
> needs isinstance(o, int) or isinstance(o, long), or float... although
> ints and longs are going to be the same. Would it be wise to let those
> have common base types?

I haven't needed that discrimination ... at least not that I can remember.
I have done some type-based dispatching, which was either very
specific (as for serialization of different data types) or special cased
only
one type, as in

   def read_it(file):
      if isinstance(file, string):
        file = open(file)
      ....

The basestring type is useful because I want to handle byte strings and
unicode strings equivalently in many cases.  But numbers as you mention?
No.

> For example:

Suppose I have this:

class Headers:
   ....
  def __getitem__(self, i):
    if isinstance(i, int):
      return self._headers_list[i]
    return self._headers_dict[i]

  def __setitem((self, k, v):
    self._headers_list.append(v)
    self._headers_dict[k] = v

  def __iter__(self):
    return iter(self._headers_list)

  def keys(self):
    return self._headers_dict.keys()
  ...

This is a specialized dict-like / list-like with mixed mutability.
(dict is more mutable, but list isn't immutable because elements
can be changed from underneath it.)

So this wouldn't be one of your types, but could be used by
code which overly asserts type checking.  Which would be sad.

Except *possibly* for the existance of a "number" type, I don't
think this suggestion gives any useful power or flexibility to
Python, while encouraging ex-statically-typed-language programmers
to do unneeded and detrimental type checks.

                    Andrew
                    dalke at dalkescientific.com