[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

An "Object" class?

On Sat, Aug 31, 2019 at 2:19 AM Cristian Cocos <cristi at ieee.org> wrote:
> Thank you! Will give the "types" module a whirl.
> Otherwise, the whole idea behind building a rigorous taxonomical hierarchy
> ("taxonomy") is to provide a simpler management of the wealth of features
> objects have. And that is because entities belonging to the same
> taxonomical class ("clade") have common features, and also inherit the
> features of the taxonomical parent. A kosher type hierarchy (or class
> taxonomy) is thus meant to answer precisely your concern about
> entity/object behavior. Now, it may be that this was not the intention of
> Python developers when they came up with the breakdown of the class of
> objects into types/classes, in which case the term "type" and derivatives
> (subtype, supertype etc.) used in this context is nothing but a regrettable
> misnomer. Then maybe I should re-direct my quest away from studying the
> type hierarchy, toward asking for built-in-object inheritance: Is there a
> diagram of built-in-object inheritance available anywhere?

Even in biology, taxonomy has its limitations. For instance, you might
assert that all birds can fly, and therefore that all members of a
subclass of birds can fly; but the Emu would like to have a word with
you. Or you might posit that all mammals give birth to live young, but
then Platypus would give you a taste of its spur. [1]

In software design, the same kinds of exceptions do occur. By and
large, principles like "anywhere that you could use the superclass,
you can equivalently use a subclass of it" will hold true, but there
are good reasons to go against them sometimes. So if you're looking
for absolute hard-and-fast taxonomic rules about Python types, you
won't find them... but you CAN expect things to generally follow rules
like LSP. That means that, for instance, any operation valid on an
instance of the vanilla 'object' type can be done on literally any
object in Python, and anything you can do with the 'type' type can be
done with any Python class. Notably, since "type" is a subclass of
"object", this means that you can manipulate types the same way that
you manipulate anything else.

As to a diagram of built-in objects... this might be of some help:


It's not fully comprehensive, but it hopefully will have some useful
information. Another neat trick is that all types have a
__subclasses__() method, so you can sometimes build up your hierarchy
that way:

>>> LookupError.__subclasses__()
[<class 'IndexError'>, <class 'KeyError'>, <class

Start from 'object' and delve from there. And when you hit 'type' in
your exploration, you'll learn something about re-entrant hierarchies
and how descriptors work :)


[1] One valid counter-argument here is that Australia is just plain
weird. I've lived here all my life, and it's certainly true.