What Is a Metaclass?

Corollary: Let S = (O, .class, ≤) be a Python core structure.

1. The structure (O ∖ {r, c}, (.class) ∪ (≺)) is a finite DAG.
2. The following are equivalent:
   1. O ≠ {r, c}.
   2. There is an object that is minimal in (.class) ∪ (≺), i.e. such that it has no instances and no strict descendants.
3. For every object x that is minimal in (.class) ∪ (≺), the restriction of S to O ∖ {x} is a Python core structure.

Disallowed structures

The first example (ⅰ) shows a cycle in inheritance. (As a consequence, ≺ is not unique – we could have drawn a green arrow from B to r instead of from A to r.) Examples (ⅱ) and (ⅲ) show ordinary objects involved in strict inheritance.

Example (ⅸ) demonstrates a violation of the monotonicity condition: A ≤ B but A.class ≰ B.class. Python detects the monotonicity break upon the B class creation, as shown by the following code:

class A()             : pass
class B(A,metaclass=A): pass # TypeError: metaclass conflict

Metaclass

As we mentioned earlier, the book does not state that the boxed sentence is the definition of a metaclass. However, the implication x ≤ c → x ∈ M appears as Theorem 4 on page 30. In Python (using the language's terminology), metaclasses are exactly the subclasses of the type class, including the type class itself. Such a delimitation can be found in many publications [] [] [] [] [] [].

We can observe that the axioms assert that

• metaclasses are classes all of whose instances are classes.

Remark: The phrase all of whose instances are classes can be found in [].

Substructures

• X.class ∪ {r} ⊆ X

The additional condition of X being an upset in ≤ results in a stronger closure property which can be expressed as either of

• (a)  X.class ∪ X.↥ ⊆ X   or   (b)  X.class ∪ X.parents ⊆ X

Decomposition lemma: Let S = (O, .class, ≤) be a structure where .class is a map on a set O and ≤ is a relation on O. Let X, Y be subsets of O such that both are subject to the (a) condition above and X ∪ Y = O. Then the following are equivalent:

1. The restrictions of S to X and Y are both Python core structures.
2. S itself is a Python core structure.

Potential instances

The vacuous truth problem can therefore be alleviated by considering possible extensions of a given Python core structure S = (O, .class, ≤) by additional objects. An object x is a class iff it has potential instances, i.e. x has at least one instance in some extension S' of S. Similarly, an object x is a metaclass iff its potential instances are classes. [] This leads to an adjustment of the classic definition:

Terminology and notation in a nutshell

• O		the set of (all) objects
  .class		the class map between objects, x.class is the class of x. As a relation, .class is called the instantiation graph or instantiation tree or also direct membership.
  ≤		the inheritance relation, a partial order on O
  <		the strict inheritance relation, the reflexive reduction of ≤
  ≺		the inheritance graph, the reflexive transitive reduction of ≤ to immediate pairs
  ϵ		the (object) membership relation between objects, equals (.class) ○ (≤), i.e. x ϵ y ↔ x.class ≤ y.
  x.↥		the set of (inheritance) ancestors of x, shorthand for {x}.↥
  x.↧		the set of (inheritance) descendants of x, shorthand for {x}.↧
  X.↥ (X.↧)		the image (resp. pre-image) of X under ≤
  x.parents		the set of (inheritance) parents of x, shorthand for {x}.parents
  X.parents		the image of X under ≺
  x.ϵ		the set of containers of x, shorthand for {x}.ϵ
  x.϶		the set of members of x, shorthand for {x}.϶
  X.ϵ (X.϶)		the image (resp. pre-image) of X under ϵ
  C		the set of classes, C = O.ϵ.↧ = r.↧ = c.϶.
  O ∖ C		the set of ordinary objects
  r		the inheritance root, the top class (named Object in the book, object in Python)
  c		the instantiation root, the top metaclass (named Class in the book, type in Python), the class of r and the only fixed point of .class
  c.↧		the set of metaclasses. The book denotes the set by M but we (try to) save this symbol for other purposes. Classes that are not metaclasses are ordinary classes.

The instance-of ambiguity

It remains to adjust appropriately all the previously made statements that used the term instance. In fact, there are just three such statements which can be expressed as follows (x denotes an object):

• x is minimal in (.class) ∪ (≺) ↔ x has no instances and no strict descendants.
• x is a metaclass → all instances of x are classes.
• x is a metaclass ↔ x is a class and all potential instances of x are classes.

In what follows we will prefer using member instead of instance.

Recursive definition

A Python core structure is a structure S = (O, .class, ≺, r) where

• O is set of objects,
• .class is the class map between objects,
• ≺ is the inheritance graph, a relation between objects,
• r is the inheritance root, a distinguished object.

The structure is then subject to the following conditions:

Proposition: The (𝕒) and (𝕓) definitions of a Python core structure are equivalent.

Proof:
Assume first that S = (O, .class, ≤) is a Python core structure according to (𝕒) and let ≺, r, c, .parents and C be derived from S according to (𝕒). We have to prove that S' = (O, .class, ≺, r) satisfies (pÿ~1)–(pÿ~7). Obviously, ≤ in S' is the same as ≤ in S and so are all of .parents, c and C (the r.↧ = C equality is stated by Proposition A1). Axioms (pÿ~1), (pÿ~3) and (pÿ~7) are the same as in (𝕒). The O.parents ⊆ C inclusion follows from (py~2). The O.class ⊆ C follows by definition of C in (𝕒). Condition (pÿ~4) follows by Corollary 2. Condition (pÿ~5) follows by C.class.↧ = c.↧ (Proposition A2). Condition (pÿ~6) follows by Corollary 3 using induction.

To show the opposite direction, assume that S = (O, .class, ≺, r) satisfies (pÿ~1)–(pÿ~7) and let ≤, c, .parents and C be derived from S according to (𝕓). We have to prove that S' = (O, .class, ≤) satisfies (py~1)–(py~7). Axioms (py~1), (py~3) and (py~7) follow by exact correspondence. If O = O.parents ∪ O.class then by (pÿ~4) S is the minimum 2-object structure and (py~∗) are easily checked. Otherwise, let x ∈ O ∖ (O.parents ∪ O.class) and let S₀ (resp. S'₀) be the restriction of S (resp. of S') to O ∖ {x}. By (pÿ~6) and the finiteness of O we can apply an induction argument and assume that S'₀ is a Python core structure according to (𝕒). Now axioms (py~5) and (py~6) follow by minimality of x in (.class) ∪ (≺). Axiom (py~2) follows by x.parents ⊆ r.↧ and the equivalence:   y is a class in S'₀ ↔ y is a class in S' and y ≠ x. Finally, to show (py~4) assume that x is a class in S', i.e. x.class ≤ a.class(2) for some object a. Since a is necessarily different from x it follows by Proposition A2 that x.class ≤ c. Consequently, x ≤ r by (pÿ~5).

New object creation

• q is the requested class, and
• P is the requested (possibly empty) set of inheritance parents,

Python provides several ways how to create new objects but for practical reasons there is no single built-in method capable of creating both ordinary objects as well as classes. The above described new object creation can be artifically assembled using the object.__new__ and type.__new__ built-in methods as shown by the new function defined in the following code.

import inspect; isclass = inspect.isclass; r = object; c = type
def new(q,P=()):
  if   not isclass(q):      assert(False)
  elif not issubclass(q,c): assert(not P); return r.__new__(q)
  else:                     assert(P);     return c.__new__(q,'',P,{})

The following diagram demonstrates the incremental creation of a Python core structure. During the last execution of new, a violation of the monotonicity condition is detected (reported as a metaclass conflict).

r = object
c = type
M = new(c,(c,))
N = new(c,(c,))
A = new(M,(r,))
B = new(N,(A,)) # TypeError: metaclass conflict

Axiomatization via ϵ

• .class is the smallest relation R (w.r.t. set inclusion) such that R ○ (≤) = (ϵ).

The box on the right shows an axiomatization of Python core structures in the (O, ϵ, ≤, r, c) signature. The two distinguished objects r and c are added for convenience. Axiom (pϵ~6) asserts the acyclicity of ϵ outside {r,c} (ϵ⁺/϶⁺ denote the transitive closure of ϵ/϶ and X² is a shorthand for the cartesian product X × X). The existence of the least container x.class for every object x is stated as axiom (pϵ~8). This condition is also known as single classification []. (The absence of the condition results in a multiple classification.)

Documents [] and [] define a slight generalization, called canonical primary structures, allowing infinitely many ordinary objects and also allowing additional ancestors of c, just like in the (ⅷ) example of disallowed structures.

Class map reduction

• (≤) ○ R ○ (≤) = (ϵ).

Various expressions of C and M

Using the notation for images and pre-images under ≤ and ϵ we can express the implicit equalities of the table as follows:

• C = O.class(2).϶ = O.ϵ.↧ = C.↥.↧ = M.class(-1) = r.↧ = c.϶,
• M = O.class(2).↧ = C.class.↧ = M.↧ = c.↧.

The book's axiomatization

An fd-core structure is a structure S = (O, .class, ≺, Class) where

• O is set of objects,
• .class is a map between objects,
• ≺ is a relation between objects (isSubclassOf),
• Class is a distinguished object.

• (∗)   x is a class   iff   x isA Class.

As already pointed out before, there is no single list in the book that would put the conditions together. Moreover, there is no direct statement of the (∗) equivalence for the delimitation of classes. Instead, the equivalence is established as a consequence of the following:

1. An object x responds to a given method defined exclusively in a class y   iff   x isA y.
2. An object x responds to the makeInstance method   iff   x is a class.
3. The Class class is the only class that defines the makeInstance method.

Summary

• .class, the instantiation graph, and
• ≤, the inheritance relation, reducible to ≺, the inheritance graph.

The set M of metaclasses arises by definitional extension, together with the set C of classes. There is also a distinguished class r and a distinguished metaclass c. These two objects form a circular substructure, r.class = c.class = c ≺ r. We have established convenient notation .↥ / .↧ for images and pre-images under the inheritance relation ≤. Moreover, we introduced a special symbol ϵ for the composition (.class) ○ (≤) and call this relation (object) membership. (In contrast to ≤, we use the ϵ symbol directly for the correspondent image map.)

We have defined metaclasses as the descendants of c, which we defined to be the class of r, which we defined to be the top of the set C of classes, which we defined to be the image of O under (.class) ○ (.class) ○ (϶). We could have defined the set M directly just like C – as the image of O under (.class) ○ (.class) ○ (≥). The primary classic definition (◉) appears as a statement about metaclasses: if an object x is a metaclass then all its instances are classes. The reverse implication can be established by resorting to potential instances, i.e. considering the instances of x in any extension of the given Python core structure. This yields three equivalent definitions which are summarized in the following list:

1. Metaclasses are the descendants of the built-in metaclass c.
2. Metaclasses are the classes of classes and their descendants.
3. Metaclasses are the classes all of whose potential instances are classes.

The F&D model, part 2: Linearization

The next family of structures just adds a single definitory constituent that induces a linear order on the set x.↥ of inheritance ancestors for each object x. That is, for each object x, there is a list x.ancs of all ancestors of x, called the linearization of x (this term is introduced in the book). This order is in accordance with inheritance – it is a linear extension of (x.↥, ≤). As a consequence, in the case of single inheritance – when each object has at most one inheritance parent (i.e. (C, ≤) is a tree) – the linearization is uniquely given. A proper refinement of FD₁ structures only takes place in the case of multiple inheritance.

FD₂ structure

• ≤_mro is a relation between ordered pairs of objects called method resolution order, shortly MRO.

• (a,x) ≤ (a,y) ↔ (b,x) ≤ (b,y)     for every pair x, y of common ancestors of a and b.

• (a,x) ≤ (a,y) ↔ there are natural i, j such that a.ancs[i] = x and a.ancs[j] = y and i ≤ j.

• if a ≤ b then b.ancs is a sublist of a.ancs.

• (A,X) < (A,Y) < (A,Z) and (B,Z) < (B,Y).

r = object
c = type
Y = c('',(     ),{})
Z = c('',(     ),{})
X = c('',(Y,   ),{})
A = c('',(X,Y,Z),{})
B = c('',(  Z,Y),{})

print(r.__mro__ == (r,)
  and c.__mro__ == (c,r)
  and Y.__mro__ == (Y,r)
  and Z.__mro__ == (Z,r)
  and X.__mro__ == (X,Y,r)
  and A.__mro__ == (A,X,Y,Z,r)
  and B.__mro__ == (B,Z,Y,r)) # True

Consistency with inheritance

• (∗)   a ≤ x ≤ y → (a,x) ≤ (a,y).

Proof: Assume a ≤ x ≤ y. By (fd₂~3)(b), a and x are MRO-compatible and thus (a,x) ≤ (a,y) ↔ (x,x) ≤ (x,y). The right side of ↔ is then asserted by (fd₂~3)(a).

C3 linearization

Given the requested local precedence order ps, let ≺_ps be the relation on P.↥ defined by

We can of course specify as purely in terms of lists. Let n be the length of ps (i.e. n equals the number of elements of P). Then as is a list containing exactly the members of lists ps[i].ancs, i < n, without duplicates, (equivalently as is a permutation of P.↥), and such that each of the lists ps and ps[i].ancs, i < n, is a sublist of as.

In general, there are multiple linear extensions of ≺_ps (i.e. there can be multiple lists as for a given list ps). A deterministic prescription is provided below. Given an FD₂ structure S = (O, .class, ≤, ≤_mro), let c3 be a partial map between finite lists of objects such that c3(ps) is a list that encodes a linear extension of ≺_ps, whenever it exists, as follows:

c3(ps)	is undefined		if ≺ps is not a DAG (i.e. there is a cycle in ≺ps), else
c3(ps)	=	c3(ps, [ ])	where the 2-argument version of c3 is defined recursively by
c3(ps,as)	=	as	if rng(as) = P.↥ (i.e. if as contains all elements of P.↥), else
		c3(ps,as+[u])	where u is the unique class such that u is minimal in (P.↥ ∖ as, ≺ps), and if v is another class minimal in (P.↥ ∖ as, ≺ps) and i (resp. j) is the least index such that ps[i] ≤ u (resp. ps[j] ≤ v) then i ≤ j.

The above prescription can be expressed as an algorithm for incremental computation of c3(ps). Given the ps list, let as be an initial part of the to-be-computed list c3(ps). Start with as being an empty list. Then append repeatedly an element of P.↥ at the end of as until it contains all elements of P.↥. (The as list is then the resulting value of c3(ps).) In each step, choose the appended member to be a minimal element u of the (P.↥ ∖ as, ≺_ps) digraph (i.e. the digraph is formed as the restriction of ≺_ps to the set P.↥ ∖ as of the not-yet-sorted classes). If there is no such u then ≺_ps is not acyclic and therefore c3(ps) is undefined. If there are more possible u's then choose that one from ps[i].↥ (equivalently, from the ps[i].ancs list) with i the smallest possible.

It can be observed that this is just a standard topological sort algorithm (see e.g. [], Algorithm 3.2.1) endowed with a deterministic choice of minimum element in each step (the choice is given by condition (ⅱ)). Alternatively, the c3 map can be expressed in terms of an operation on lists of lists. (This is in fact the standard description [].) The minimality of u is expressed as the u's occurrence in a head of a list to be processed and, simultaneously, the u's non-occurrence in a tail of any list. The diagram on the right shows an example in which ps has four members, so that the input list of lists equals [ps[0].ancs, …, ps[3].ancs, ps]. The classes to be processed (after a partial evaluation of c3(ps)) are displayed in green.

Why C3?

1. (1) monotonicity,
2. (2) preservation of the requested local precedence order,
3. (3) consistency with the extended precedence graph.

• a ⊳ps b ↔

  ps[i] ≤ a and ps[j] ≤ b for some i < j.

• a ⊳_ps b ⋪_ps a → a = as[i] and b = as[j] for some i < j

The F&D model, part 3: Methods

FD₃ structure

• Σ is the set of names,
• Π is the set of (anonymous) methods,
• .π is a partial function from O to Π called method valuation,
• .m_ɵ() is a partial function from O × Σ to Π called the own method map.

The .π map is an auxiliary constituent which allows some ordinary objects to serve as handles of methods. In a potential further refinement of the F&D model, there can be a distinguished class F that serves as a classifier for the domain of .π, as does the class named function in Python.

Named method ownership, provision and respondence

• x.ɯ(s) = y ↔	y = x.ancs[i] for the smallest i such that x.ancs[i].mɵ(s) is defined,
  x.mʜ(s) = x.ɯ(s).mɵ(s),
  x.mʀ(s) = x.class.mʜ(s).

Note: (⁎) The statement x responds to (s,f) should be understood as an abbreviation of x responds to an s-named message by (invoking) f.

Observations:

1. If x owns (s,f) then it also inherits (s,f).   (That is, .m_ɵ() ⊆ .m_ʜ() – ownership implies provision.)
2. x.ɯ(s) = x ↔ x owns (s,f) for some method f.
3. If x inherits (s,f) then x.ɯ(s) owns (s,f).
4. If x inherits (s,f) and x ≤ y ≤ x.ɯ(s) then y inherits (s,f).
5. All named methods owned by a class x are received by all x's direct instances.

Method dictionaries

• x.m_ʜ() = a₀ ◐ a₁ ◐ ⋯ ◐ a_n-1    (the dictionary of inherited methods of x)

• a ◐ b = c where c is the unique dictionary such that c[s]	= a[s]	if a[s] is defined else
  	= b[s]	if b[s] is defined else c[s] is undefined.

Observations:

1. There is no need for parentheses in a₀ ◐ a₁ ◐ ⋯ ◐ a_n-1 since ◐ is associative.
2. For every ordinary object x, both x.m_ɵ() and x.m_ʜ() are empty. (A consequence of (fd₃~1).)
3. If x and y are direct instances of the same class then the dictionaries x.m_ʀ() and y.m_ʀ() are identical.

p = {'x' : 1, 'y' : 2}
q = {'x' : 1, 'y' : 2}
print (p is q) # False
print (p == q) # True
p = q
print (p is q) # True

Note: (⁎) We use the term dictionary as a synonym to finite functional relation – a dictionary is a finite set of key-value pairs with unique keys. Exactly the same definition is introduced in the book (Definition 1, page 4). In contrast, Python's dictionaries are associative arrays. They are objects used to represent functional relations, but without a one-to-one correspondence. In the code on the right, after the execution of the first 2 lines, p and q are non-identical objects representing the same functional relations. After the p = q assignment, p and q become identical.

Method arrows

The diagram below shows a sample FD₃ structure with just one own method arrow (.m_ɵ() = {(A,s,f)}). The induced relation of named method respondence is indicated by dashed lines (there are exactly 2 received method arrows). Since A has exactly one strict descendant, there is also one arrow in the strict provision relation .m_ʜ() ∖ .m_ɵ() (namely (B,s,f)) which is however not displayed.

def f(self): print ('@-' + str(id(self)))
s = 'm'
class A:    pass
class B(A): pass
e = A()
u = B()
setattr(A,s,f)            # A.m = f
em = getattr(e,s); em()   # em = e.m; @-9828912
um = getattr(u,s); um()   # um = u.m; @-9829008
_m = getattr(e,s)         # _m = e.m
print (em)         # <bound method A.f of (...)
print (_m is em)          # False
print (em.__self__ is e)  # True
print (em.__func__ is f)  # True

Observe also that in the Python code, f denotes an object, whereas in the diagram, f (in obligue font) denotes a method. Here we assume that f = f.π, i.e. f is the method valuation of the f object. The diagram above could be refined by the diagram on the right to reflect this correspondence. The olive arrow indicates the .π map, and F denotes the built-in class (named 'function') that is the class of f.

Note: (⁎) To be precise, Python does not perform reification of (x,s,f) but just of (x,f) – the s name (equal to 'm') is lost. This is indicated by the textual representation of em which (erroneously) refers to A.f instead of to A.m.

Transitions

The following table shows the corresponding Python and SQL expressions. We use own_method_arrows as the name for the database table.

class A:
  def m(self): print (…)

As for the (auxiliary) method valuation map .π, we only allow incremental transitions – the value of x.π (or its definedness) for an old object x cannot be changed.

Alternatively, core structures (O, .class, ≤_mro) serve as generators of received method arrows. These implicit entities are generated from owned method arrows (the explicit entities) and are then used for method invocation.

Method invocation

• x is the receiver object on which the method is invoked,
• s is the name of the method to be invoked, and
• ℓ = a₁,…,a_n is the possibly empty list of arguments with which the method is invoked.

• x.<s>(a1,…,an)

Returned value

Methods that have no side effects and take no arguments have a prominent position. Every such method f defines a partial map between objects. If x responds to (s,f) and x.<s>() evaluates to y then the pair (s,y) can be regarded as an attribute of x. To support this semantics, we let x.<s> be a shorthand for x.<s>(). As a canonical example of use, if f is a method that returns the class of the object upon which f is invoked and the inheritance root r owns the named method ('class',f) then

• x.class evaluates to x.class for every object x,

Execution context

1. Set self to x.
2. Evaluate the code of f.
3. Reset self to the value that it was assigned to before (1).

The F&D model, part 4: Data valuation

Unlike with named methods, there is no support for sharing of named objects from x.ю(). That is, there is no distinction between ownership and respondence for .ю(). In contrast to the book, we simplify the situation and allow arbitrary dictionaries x.ю(), similarly to Python. In particular, we do not require compatibility of instance variables – x.ю() and y.ю() can have different domain (different set of keys) even if x.class = y.class.

The (x.ю(), x.φ, x.m_ʀ()) structure shown by the diagram constitutes what can be called perceived object properties. Typically, the syntax of a programming language is maximally tuned for the access and manipulation of these properties. A relational database counterpart of the diagram looks as follows:

FD₄ structure

• Φ is the set of values, alternatively, the value domain,
• .φ is a partial function from O to Φ called object data valuation,
• .ю() is a partial function from O × Σ to O called the instance variable valuation.

class S(str): pass
s1 = 'abc'; t1 = S('abc')
s2 = 'abc'; t2 = S('abc')
print (s1 is s2) # True
print (t1 is t2) # False

s1 = '__init__'
s2 = 'm'
def f1(self,greet): self.greet = greet
def f2(self): print ('h-' + self.greet)
def f3(self): print ('-h' + self)
class A:      pass
class S(str): pass
class B(A,S): pass
setattr (A,s1,f1)      # A.__init__ = f1
setattr (A,s2,f2)      # A.m = f2
setattr (S,s2,f3)      # S.m = f3
el = S('ello'); el.m() # -hello
ul = S('ullo'); ul.m() # -hullo
e = A(el); e.m()       # h-ello
u = B(ul); u.m()       # h-ullo
print (el,ul,u)        # ello ullo ullo

Transitions

Instance variable access

• @<s> evaluates to self.ю(s)   (whenever self.ю(s) is defined).

This way we support the well-known paradigm of object oriented programming: Instance variables of an object x can only be accessed via methods to which x responds.

FD₁ to FD₄ in a summary

• FD₁ structures (O, .class, ≤), also called Python core structures, are constituted by instantiation and inheritance graphs. These are the two most fundamental relations between objects and they are already sufficient for the definition of the metaclass term. In the diagrams, we use blue arrows for the instantiation graph and green arrows for the inheritance graph.
• FD₂ structures (O, .class, ≤, ≤_mro) provide an ordering between inheritance-related pairs of objects, known as method resolution order (MRO). As a result, each object has defined a linear ordering of its inheritance ancestors. This ordering is consistent with the inheritance relation so that the ≤_mro constituent brings additional information only in the case of multiple inheritance. In the diagrams, we use magenta arrows to indicate the part of MRO that is not implied by inheritance. The source and target of a magenta arrow is a green arrow.
• FD₃ structures (O, Σ, Π, .class, ≤, ≤_mro, .π, .m_ɵ()) introduce additional sorts of names (Σ) and methods (Π). The last constituent, .m_ɵ(), is a partial map from O × Σ to Π and can also be regarded as a relation of ownership between objects (O) and named methods (Σ × Π). There is an induced partial map from O × Σ to Π, denoted .m_ʀ(), which can be regarded as the relation of respondence between objects and named methods. For each object x, the dictionary x.m_ʀ() of named methods to which x responds equals the merge of the dictionaries y.m_ɵ() of named methods owned by inheritance ancestors y of x.class. The precedence of the merged dictionaries is given by method resolution order. In the diagrams, we use solid brown arrows to indicate named method ownership and dashed brown arrows to indicate the respondence.

  The .π constituent is an auxiliary partial map from O to Π that can be used to refer to methods via objects. We have reserved the olive color for the diagrammatization of .π.

• FD₄ structures (O, Σ, Π, Φ, .class, ≤, ≤_mro, .π, .m_ɵ(), .φ, .ю()) introduce the additional sort of values (Φ) which are assigned to some objects via the .φ map. The Φ set is meant to comprise some commonly understood data domains like integers, strings or booleans. The .ю() constituent is a partial map from O × Σ to O, called the instance variable valuation, which equips each object x with a dictionary x.ю() of named objects. (That is, x.ю() is the valuation of instance variables of x.) This dictionary, together with the (optional) .φ-valuation of x, constitutes the object x data (alternatively, state). According to a fundamental paradigm of object-oriented programming, x.ю() can only be manipulated via elements of x.m_ʀ() – the named methods to which x responds.

• solid brown arrows → dashed brown arrows.

Object neighbourhood

Essence of OOP with metaclasses

1. Objects are fundamental entities of OOP. Each object has data and responds to messages via methods that manipulate the data.
2. Every object is a direct instance of a class – an entity that provides the methods with which the object responds to messages sent to it.
3. Classes are objects. (The metaclass pre-condition.)
4. Classes, as method providers, are built incrementally.

Python core structure in Python

Let us assume that (1) or (2) is the Python's definition of possible combinations of the instantiation and inheritance graphs. Given this, does Python conform to the axiomatization of Python core structures? The answer is: no. We will see that conformance is asserted for neither of (1) or (2) and that the two definitions are in general not consistent. As for (1), Python allows explicit setting of both __class__ and __mro__ attributes of objects without making sufficient checks that all of (py~1)–(py~7) are satisfied.

As for (2), isinstance and issubclass are introspection methods that can be overridden: if a class y responds to a named method ('__instancecheck__',f) (owned necessarily by a metaclass) then isinstance(x,y) will evaluate to y.f(x) for all objects x (that are not direct instances of y – another Python speciality). Similarly, issubclass(x,y) can be overridden by defining __subclasscheck__ in y.class. Moreover, even overrides made by Python's standard library via abstract-base-classes do not respect all the axioms.

class A: pass
x = A()
try: issubclass(x,x)
except Exception as e: print(e)
# issubclass() arg 1 must be a class
x.__bases__ = ()
print (issubclass(x,x)) # True
isinstance(x,x)       # False but OK

In the issubclass(x,y) expression, both arguments are required to be classes (otherwise an exception is raised). The issubclass method puts this constraint to just the second argument. However, according to the Python documentation [] both methods have an altered recognition of classes, shown by the code on the right: if x.__bases__ evaluates to a tuple of instances of c then x is regarded as a class.

Subverting __class__

r = object
c = type
M = c('',(c,),{})
N = c('',(c,),{})
A = M('',(  ),{})
B = M('',(A,),{})
B.__class__ = N

r = object
c = type
dummy = c('',(c,),{})
A = dummy('',(c,),{})
B = dummy('',(c,),{})
B.__class__ = A
A.__class__ = B

r = object
c = type
dummy = c('',(c, ),{})
P = dummy('',(   ),{})
Q = dummy('',(P,c),{})
Q.__class__ = Q
P.__class__ = Q

Subverting __mro__

r = object
c = type
def P_mro(self): return [self]
def Q_mro(self): return [self,P]
M = c('',(c,),{})
M.mro = P_mro; P = M('',(M,),{})
M.mro = Q_mro; Q = M('',(M,),{})
P.__class__ = Q
Q.__class__ = Q

class M(type):
  def mro(self): return []
A = M('',(),{})
A.xx = 41
print (A.__mro__)       # ()
print (issubclass(A,A)) # False
print (hasattr(A,'xx')) # False

The __mro__ attribute can also be subverted to achieve a violation of (py~1). That is, Python does not guarantee that inheritance, as induced by __mro__, is a partial order. The code on the right demonstrates possible irreflexivity – the A class is not its own descendant. Similarly, there can be transitivity breaks. In contrast, antisymmetry seems to be guaranteed (or at least substantially harder to break).

Abstract base classes

from collections import Hashable
print(issubclass(list, object))     # True
print(issubclass(object, Hashable)) # True
print(issubclass(list, Hashable))   # False

Superclass linearization

c = type
class P: pass
class M(c):
  def mro(self): return (c,c)
A = M('',(P,M),{})
print (A.__bases__ == (P,M)
  and  A.__mro__   == (c,c)) # True
A.__bases__ = (M,M)
print (A.__bases__ == (M,M)) # True

Presumably, the __bases__ attribute is of little importance to the Python data model. In particular, the inheritance relation ≤ is based on __mro__ and disregards __bases__.

Python attributes

Things change substantially when going to FD₃ and FD₄ structures. In contrast to our model which keeps methods separate from instance variables and only applies the (O, .class, ≤_mro) structure for the sharing of named methods, Python blends the two things together into attributes. This is in turn based on blending inheritance with object membership.

Blending ≤ with ϵ

• x.ꙗ() = x.ꙗ_ʜ() ◐ x.ꙗ_ʀ().

The resolved attributes of x are those inherited by x.class updated by those inherited by x.

Default semantics of x.<s>

class M(type): pass
class N(M): pass
class A(metaclass=N): pass
class B(A): pass
b = B()
M.m = 41; M.n = 30; A.n = 26
print (B.m,B.n,b.n) # 41 26 26
try: b.m
except Exception as e: print(e)
#'B' object has no attribute 'm'

• x.<s> is evaluated to x.ꙗ(s).

Method resolution

Python is at odds with the above described mechanism, mainly due to the blending of inheritance (≤) with membership (ϵ). In Python, some objects x are callable. Let us regard them as .π-valued, but use the term function for x.π rather than method. In a typical program, most Python's callable objects are instances of the built-in class referred to by types.FunctionType and named function. (In contrast to object or type the class is not by default available under its name but we will use the name to refer to the class.)

def y(self=0): print (self)
class A: pass
class B(A): pass
A.m = y
x = B  ; x.m()                 # 0
x      ; print (x.m is y)      # True
x = B(); print (x.m is y)      # False
x      ; x.m() # <__main__.B object ...
print (y.__class__.__name__) # function
print (x.m.__class__.__name__) # method

Instances of function play a special role in attribute resolution. Let y be such an instance. If (x,s) resolves to y via ϵ then the evaluation of x.<s> results in a new object p that is a reification of (x,y). Such reifications are called bound methods and are instances of the built-in class types.MethodType which reports itself as method. The expression x.<s>(a1,…,an) is evaluated in two steps as

• p = x.<s>;  p(a1,…,an)

In contrast, if (x,s) resolves to y via ≤ then evaluation of x.<s> results just in y, i.e. it has the default semantics according to the previous subsection. As of Python 3, no reification takes place. (This differs from previous versions of Python [].) As a consequence, x.<s>(a1,…,an) is interpreted as y(a1,…,an) – the context of the x object is lost.

Faking __class__ and __mro__

class M(type):        __mro__   = 55
class A(metaclass=M): __class__ = 33
a = A()
print (A.__mro__)             # 55
print (a.__class__)           # 33
print (type(a) is A)          # True

Unfortunately, the two dictionaries can share some keys – that is, attributes in the second dictionary can have special names. In some cases, such attributes have impact to attribute resolution. The code on the right shows that both __class__ and __mro__ can be faked this way. This is different from the subversion demonstrated before since the real attributes remain unchanged. They are just shadowed. The last line indicates that for the introspection of the class of x,   type(x) is more reliable than x.__class__. There is no counterpart to __mro__ (known to the author), although in the code, A.mro() would evaluate to [A,object]. However, this just invokes the (recomputation of) C3 linearization and relies on A.__bases__ which can be subverted.

The is-a misnomer

• x is a y,
• x is a member of y,   (x ϵ y)
• x is an instance of y. (Recall that we follow the Python's terminology here and allow indirect instances.)

• John is a student is a case of x is a y where x equals to John and y equals to student.
• a student is a person is a case of x is a y where x equals to a student and y equals to person.

Unfortunately, exactly this mistake happened in the early days of information technology and has not yet been rectified. As can be observed on the wikipedia page titled Is-a, in most publications, is-a refers to ≤ (instead of ϵ). This is despite the fact that in the field of knowledge representation, the problem of confusion of ϵ with ≤ has already been recognized in the 1970s (!), see [] or [] where infamous "ISA" links are mentioned.

The opportunity has been seized in favor of inheritance, ≤. The reasoning goes as follows. If B and T are classes such that B ≤ T (think of the names as of abbreviations for Beech and Tree) then one can say that

• a B is a T,

• there is an is-a relationship between B and T.

• a B is a T   ⇢   B is a T,

The correct is-a

Note: The lunate epsilon symbol 'ϵ' [] [] which we have introduced for object membership was used by Giuseppe Peano in 1889 for set membership []. According to Peano, a ϵ b is read as a est quoddam b (in Latin) which means a is a b (in English) []. This demonstrates a correct use of is-a. The image on the left displays the assumed rendering of the unicode character U+03F5.

In a Python core structure, objects are exactly the Objects and classes are exactly the Classes whenever Object is the name of the inheritance root r and Class is the name of the instantiation root c, just like proposed by the F&D model. In a potential generalization of Python core structures, the naming convention can be used for a subtle differentiation. This has already been shown for the case of Java core structures, where classes are (among) Classes but the reverse inclusion does not hold.

is-a versus has-a

The following equivalences show the definition of has-a as it corresponds to our definition of is-a. In an FD₄ structure, for every objects x, y,

In the previous subsections, we have recognized ≤ as the overridden definition of is-a used in class diagrams. Now we have the non-overridden definition of has-a. What is the correspondent relation used in class diagrams? Let us refer to this relation by HAS. For convenience, let SUB be an additional term for inheritance (an abbreviation of subsumption). The answer can be then expressed as follows. In an FD₄ structure that is sufficiently saturated, for every classes a, b,

• a SUB b	↔	a.϶ ⊆ b.϶,
  a HAS b	↔	a.϶.ю(s) ⊆ b.϶ for some name s.

Finally, the HAS relation is usually considered in a more strict sense where there is equality instead of inclusion, so that a HAS b iff b is the classifier for a.϶.ю(s) for some s. (That is, even though a car has a wheel and a wheel is an object, it is not usually stated that a car has an object.)

The OOP landscape of metaclasses

1. Recognize the core structure: Figure out what the blue and green links are in given circumstances.
2. Make judgements about what combinations of blue and green links are allowed.
3. Establish the definition of a metaclass.

The following table provides a partial outline of the considered OOP environments in a chronological order.

• An implicit metaclass y is a metaclass that has a top member x – all potential members of y are descendants of x, written as x.↧ = y.϶. In particular, y.϶ ≠ ∅.
• An explicit metaclass y is a metaclass that is not implicit, i.e. y.϶ is potentially topless, allowing y.϶ = ∅.

Smalltalk-76

Metaclasses were invented by Smalltalk-76 in order to express the behavior of classes as true objects able to handle message passing.

The structure of instantiation and inheritance in Smalltalk-76 arises as a simplification of Python core structures. Let Smalltalk-76 core structure be a structure (O, .class, ≤, r) where

• O is a set of objects,
• .class is the class map O → O,
• ≤ is the inheritance relation between objects, and
• r is a distinguished object.

Observe that a Smalltalk-76 core structure is a Python core structure satisfying the following two constraints:

ObjVLisp

In some aspects, papers [] [] can be regarded as precursors to the F&D book although no such claim appears in the book. There are several points in the papers that can be used to enhance the description of the core structure. We already did so by adopting the term instantiation graph as the missing counterpart to the inheritance graph. Yet more remarkable is the term terminal instances which is correspondent to ordinary objects from the F&D book. We will futher adopt the adjective terminal and introduce the following new terminology and notation. In a Python core structure, let

• T be the set O ∖ O.ϵ.↧ and call elements of T terminal(s).

Moreover, terminal can be used to overcome the ambiguity of ordinary. (Recall that by the F&D book, ordinary object is an object that is not a class and ordinary class is a class that is not a metaclass. Assume that x is an ordinary class. Being a class, x is an object. Is x ordinary?)

Note: The term terminal objects for objects that have no instantiation semantics is used in [].

LOOPS

Metaclasses in CLOS

The CLISP built-in core structure

The set X of selected objects is (presumably) the smallest one such that

• the r object (named t or also T to resemble the ⊤ symbol for top) is in X,
• X is closed w.r.t .class and .↥ (see Substructures),
• every descendant x of r for which x.ͼlass is defined is in X, (x is one of r, so, to, fso or gf)
• every descendant of mo (which is named metaobject) is in X.

What is a class?

However, the presumed family of CLOS core structures is still close to Python core structures:

• The .class map forms a tree according to the diagram on the right. The root of the tree is r.class(2) rather than r.class. (The root is the sc class, named standard-class. Observe that although {sc} is the only cycle of .class, it cannot be used as a classifier for classes – not every class is an instance of sc.)
• Although there are built-in monotonicity breaks, the CLISP interpreter performs checks of .class monotonicity for user-created classes. []

What the literature says

• the book titled The Art of the Metaobject Protocol (AMOP) [],
• the book titled Common Lisp the Language [], and
• the html document titled Common Lisp HyperSpec [].

The term class metaobject is used for the backstage structure that represents the classes …  (Page 18)

In contrast, the book [] considers classes to be (among) objects just like in Python or the F&D model: A class is an object that determines the structure and behavior of a set of other objects, which are called its instances. Similarly, The function class-of returns the class of which the given object is an instance. The same approach is taken in the Common Lisp HyperSpec document [] except for one occurrence of Classes are represented by objects []. However, the CLISP document [] which builds upon both AMOP and HyperSpec again oscillates between the two approaches.

What is a metaclass?

We refrain from using the term metaclass for classes like standard-class, choosing to use the more explicit phrase: class metaobject class. The sole exception is an option we will add to defclass called :metaclass, which has been retained for historical reasons.  (Page 75)

• c = ∨C.class,

S. Koide and H. Takeda define CLOS metaclasses as the (non-strict) subclasses of standard-class (sc) [] []. In a parallel to RDF Schema, they assume that being a fixpoint of .class is the definitory characteristic for the top metaclass, disregarding built-in breaks of monotonicity of .class.

Is java.lang.Class a metaclass?

The code on the right uses the introspection methods getSuperclass (defined in Class) and getClass (defined in Object) to demonstrate that

class X {public static void main(String[] x){
  Class
  r = Object.class,
  c = Class.class; System.out.println (
  r.getSuperclass() == null &&
  c.getSuperclass() == r    &&
  r.getClass()      == c    &&
  c.getClass()      == c );     // true
}}

Indeed, this is exactly what the F&D book [] states. Quoting from page 42: Java has a single metaclass Class of which all classes are instances. This statement is confirmed in [] and in particular in another book by Ira R. Forman, this time co-authored by Nate Forman, and titled Java Reflection in Action []. The book appeared in 2005, seven years after the F&D book, with praiseful notes from Doug Lea [] and John Vlissides []. Quoting from page 23 of []:

Class is an example of a metaclass, which is a term used to describe classes whose instances are classes. Class is Java's only metaclass.

Are classes objects?

The method getClass returns the Class object that represents the class of the object. (§4.3.2 []).

Class reification

Java uses the very strange syntax <s>.class for the reification of the s-named class. In the code above, assignments r = Object.class and c = Class.class let r be the reification of the Object class and c be the reification of the Class class. Note also that the distinction between class and its class object, although quite consistently adhered to by Java documentation, is not reflected by the names of introspection methods: for an object x, x.getClass() does not evaluate to the class of x but to the reification of the class of x.

Now we can attempt to further adjust the classic definition so that it works even with respect to a reification:

• Metaclasses are classes all of whose potential instances are reifications of classes.

Java core structure

For simplicity, we exclude the nine distinguished instances of the Class class that represent primitive types (boolean, byte, char, short, int, long, float, and double) or void. To handle these objects properly (i.e. as classes and thus descendants of r) it would be necessary to introduce an additional ancestor of the Object class – just like in the case of the Scala programming language which rectifies these Java's conceptual shortcomings by introducing the Any class as the new inheritance root.

The definition below is a modification of that of Smalltalk-76 core structures. The set C is again defined as r.↧, but the term class is used only for objects from a distinguished subset Ͼ of C. The complementary subset is that of interfaces. To establish such a distinction an additional definitory constituent is required. This constituent could be directly set to Ͼ. However, it turns out that Ͼ forms a closure system in (C, ≤) – for every interface x there is a least class y that is an ancestor of x. This defines a closure operator, .c, that is actually used in the signature. (In an analogy to ≤, we let .c be a total map on O so that ordinary objects become fixpoints of .c, in addition to classes.)

A Java core structure is a structure (O, .class, ≤, r, .c) where

• O is a set of objects,
• .class is the class map between objects
• ≤ is the inheritance relation between objects,
• r is the inheritance root, a distinguished object,
• .c is a map between objects.

The last axiom says that in Java, the non-identity part of .c is simply a constant map to {r}. That is, interfaces are not interleaved with classes. This is in contrast to Scala, where a trait (the Scala's counterpart to Java's interface) can in general inherit from any class that is not final.

Class
r  = Object.class,
c  = Class.class,
ae = AnnotatedElement.class,
gd = GenericDeclaration.class,
s  = Serializable.class,
t  = Type.class;

It can be observed that Smalltalk-76 core structures are a special case of Java core structures – those without interfaces (i.e. such that .c is identity, equivalently, Ͼ = C).

The diagram on the right shows the built-in circular structure of Java 8. The six objects, four of which are interfaces, are exactly the objects x such that x ϵ x (that is, x.isInstance(x) evaluates to true). The .class map is shown in the restriction to classes.

What is a metaclass?

The definition of metaclasses as descendants of classes of classes applies as well. However, the classic definition has to be adjusted. To do this, we apply the classifier naming convention for the Class class: instances of this class are referred to as Classes. The proper adjustment of the classic definition is then as follows:

Note: In [], the built-in Java classes Method and Field from the java.lang.reflect package are given as examples of metaclasses. However, in subsequent considerations applied within a similar model for a class named Property the author concedes that the term metaentity might be more appropriate.

The Perl's isa

In what follows we only consider classes and their instances as they are (presumably) understood in Perl. That is, in Perl 5, class is synonymous to package and can be created using the package keyword. An instance of a class x is an entity that is blessed into x using the built-in bless subroutine. In Perl 6, a class x is an entity created using the class keyword. Instances of x are created by invocation of the new method on them: x.new evaluates to a new instance of x. We regard Perl's classes and their instances as objects. This uniformity is based on a substantial common property of these entities, namely that both are potential invocants, with a uniform method invocation semantics. If an s-named method is invoked upon x (by x-><s>(…) in Perl 5 or by x.<s>(…) in Perl 6) then x is passed to the body of <s> in a uniform way (either as $_[0] in Perl 5 or as self in Perl 6).

It is therefore possible to make judgements about the ϵ relation based on responsiveness to named methods. This leads to the revelation of circularity of Perl's classes:

• Every class responds to its own named methods.

• x.WHAT.WHAT === x.WHAT.

The diagram below shows a sample structure based on the above reasoning. The blue arrows indicate the ϵ relation, thickness of arrows distinguishes the .class map. In the case of Perl 6, the Mu class (which is the inheritance root) should also be displayed to make the structure closed w.r.t. .↥.

package UNIVERSAL
          { sub new { bless {},$_[0] }}
package A { sub me { $_[0] } }
package B { our @ISA = A }
my
$r = UNIVERSAL,
$b = B->new;
print ($b->me == $b &&
        B->me == B  &&
        A->me == A);   # 1

class A { method me { self } }
class B is A {}
my $r = Any;
my $b = B.new;
say ($b.me === $b &&
      B.me === B  &&
      A.me === A);     # True
say ($b.WHAT === B &&
      B.WHAT === B &&
      A.WHAT === A);   # True

The isa method

isa() returns a true value if its invocant is or derives from the named class, or if the invocant is a blessed reference to the given type.

Perl core structure

• C = O.ϵ be the set of classes,
• (O, ≤) = (C, ϵ) ∪ (O, =) be the inheritance relation,
• .class be the unique map such that (.class) ○ (≤) = (ϵ).

Observation: Perl core structures can be axiomatized in the signature (O, .class, ≤) using a slight alteration of (py~1)–(py~7):

• The set C is defined differently as O.ϵ.↧.
• Axioms (py~5) and (py~6) are replaced by the requirement of idempotency od .class.

Metaclasses in Perl 5

• (1) classes all of whose potential instances are classes,
• (2) descendants of r.class,
• (3) classes of classes and their descendants.