== Nailing down new-style classes and types in Python

Since I keep confusing myself, it's time to write this stuff down once
and for all to make sure I have it straight (even if some or all of it
is in the official documentation).

One writes Python code to define classes; it's right there in the
language syntax, where you write '_class A(object): ..._'. Defining a
class creates a type object for that class, which is an instance of
_type_; this C-level object holds necessary information about the class
and [[how it's actually implemented HowSlotsWorkI]]. This type object is
what is bound to the class name; if you define a class _A_, '_type(A)_'
will then report _<type 'type'>_.

Classes have a class inheritance hierarchy, which is ultimately rooted
at _object_ (including for C-level classes). However, strictly speaking
there is no type hierarchy as far as I know; all types are simply
instances of _type_ (including _type_ itself). Further, the type
non-hierarchy is of course unrelated to the class hierarchy. This means
that _isinstance(A, type)_ is True but _issubclass(A, type)_ is both
False and the wrong question (unless you really do have a subclass of
_type_ somewhere in your code).

(Among other things I believe that this means that '_type(type(obj))_'
is always '_type_' for any arbitrary Python object, since all objects
have a type and all types are instances of _type_.)

The [[Python documentation
http://docs.python.org/reference/datamodel.html]] sometimes talks
about a 'type hierarchy'. What it means is either 'the conceptual
hierarchy of various built-in types', such as the various forms of
numbers, mutable sequences, and so on, or 'the class inheritance
hierarchy of built-in types', since a few are subclasses of others and
everyone is a subclass of _object_.

(Some languages really do have a hierarchy of all types, with real
(abstract) types for things like 'all numeric types' or 'all mutable
sequence types', but Python does not. You can see this by inspecting the
((__mro__)) attribute on built in types to see the classes involved in
their [[method resolution order MethodResolutionOrder]]; the MRO of a
type like _int_ is just itself and _object_. Only a few built in types
are subclasses of other types.)

PS: yes, almost all of this is in the Python documentation or is implied
by it. Writing it down anyways helps me get it straight in my own head.

PPS: I believe that technically it would be possible for a sufficiently
perverse extension module to create a valid new style C-level class
that was not a subclass of _object_. Don't do that, and if you did I
expect that things would blow up sooner or later.

=== Sidebar: the real difference between classes and types

If you use _repr()_ on user-defined classes and on built in types (eg
'_repr(A)_' and '_repr(str)_'), you'll notice that it reports them
differently. This is a bit odd once you think about it, since they are
both instances of _type_ and so are using the same _repr()_ function,
yet one reports it is a 'class' and the other reports it is a 'type'.

In CPython, the difference between the two is whether the C-level
type instance structure is flagged as having been allocated on the
heap or not. A heap-allocated type instance is a class as far as
_[[type.__repr__()|]]_ is concerned; a statically allocated one is a
type. All classes defined in Python are allocated on the heap, like all
other Python-created objects, and so report as classes. Most 'types'
defined in C-level extension modules are statically defined and so get
called types, but I believe that with sufficient work you could create a
C-level type that had a heap allocated type instance and was reported as
a class.

(It's easy enough to keep it from being garbage collected out from
underneath your extension module; you just artificially increase its
reference count.)