[Tutor] The Whole Tree

[Oscar Benjamin]

On 16 June 2013 20:49, Jim Mooney <cybervigilante at gmail.com> wrote:
> On 16 June 2013 11:32, Andreas Perstinger <andipersti at gmail.com> wrote:
>
>> I'm not sure if that's what you are looking for but the language reference
>> describes the standard type hierarchy:
>> http://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
>
> Yes, that's what I meant. I was thinking of an actual visible tree,
> but it doesn't go that deep, so that wouldn't be of use.

As Steven mentioned Java has a complex inheritance tree for its
objects. However the reason for that is that Java is statically typed
and the compiler makes guarantees about the compiled code based on the
type hierarchy. Having a complex hierarchy gives programmers the
flexibility to specify broad sets of types that are acceptable in a
particular context.

For the most part in Python exactly where the type of an object
appears in some class hierarchy doesn't really matter. Consequently
there's often not really any point in putting objects into a hierarchy
unless they actually share a significant amount of code. Unless
someone goes out of their way to actually test the type of an object
with isinstance() the class hierarchy can often be considered
irrelevant.

The exception to this is exception classes. When an exception is
caught with try/except the isinstance() function is used for matching.
The exception class hierarchy is precisely what determines whether or
not an exception is caught. As a result there is something of a tree
that you can see here:
http://docs.python.org/3.3/library/exceptions.html#exception-hierarchy

Otherwise in Python what matters is in many cases is that an object
has the right methods or properties. It is common to specify (in
documentation) that the input to a function should be e.g. an
"iterable", a "sequence" or a "number" rather than explicitly require
a set of types or a subtree of a class hierarchy. This specification
implicitly designates that the object shall have certain properties
but in Python this not enforced (until you attempt to use a missing
property). This approach is similar to interfaces in Java or to the
type system of Haskell but is fuzzier than both. You can see a
representation of the core Haskell type system here:
http://www.haskell.org/onlinereport/basic.html#standard-classes

As Steven mentioned Python also has an abstract base class hierarchy.
This is unrelated to the actual class inheritance hierarchy and is
based on objects having the appropriate properties to be an "iterator"
etc. The table here describes the hierarchy and associated methods:
http://docs.python.org/dev/library/collections.abc.html

I was interested to see how that would look as a tree so I constructed
a dot file for the graph:

$ cat collections.dot
digraph G{
    Container
    Hashable
    Iterable
    Iterable -> Iterator
    Callable
    {Sized Iterable Container} -> Sequence
    Sequence -> MutableSequence
    {Sized Iterable Container} -> Set
    Set -> MutableSet
    {Sized Iterable Container} -> Mapping
    Mapping -> MutableMapping
    Sized -> MappingView
    {MappingView Set} -> ItemsView
    {MappingView Set} -> KeysView
    MappingView -> ValuesView
}

If you have graphviz installed you can turn this into a png image with:

$ dot -Tpng -o collections.png < collections.dot


Oscar