On 16 June 2013 20:49, Jim Mooney <cybervigila...@gmail.com> wrote: > On 16 June 2013 11:32, Andreas Perstinger <andiper...@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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
