
Data model
**********


Objects, values and types
=========================

*Objects* are Python's abstraction for data.  All data in a Python
program is represented by objects or by relations between objects. (In
a sense, and in conformance to Von Neumann's model of a "stored
program computer," code is also represented by objects.)

Every object has an identity, a type and a value.  An object's
*identity* never changes once it has been created; you may think of it
as the object's address in memory.  The '``is``' operator compares the
identity of two objects; the ``id()`` function returns an integer
representing its identity (currently implemented as its address). An
object's *type* is also unchangeable. [1] An object's type determines
the operations that the object supports (e.g., "does it have a
length?") and also defines the possible values for objects of that
type.  The ``type()`` function returns an object's type (which is an
object itself).  The *value* of some objects can change.  Objects
whose value can change are said to be *mutable*; objects whose value
is unchangeable once they are created are called *immutable*. (The
value of an immutable container object that contains a reference to a
mutable object can change when the latter's value is changed; however
the container is still considered immutable, because the collection of
objects it contains cannot be changed.  So, immutability is not
strictly the same as having an unchangeable value, it is more subtle.)
An object's mutability is determined by its type; for instance,
numbers, strings and tuples are immutable, while dictionaries and
lists are mutable.

Objects are never explicitly destroyed; however, when they become
unreachable they may be garbage-collected.  An implementation is
allowed to postpone garbage collection or omit it altogether --- it is
a matter of implementation quality how garbage collection is
implemented, as long as no objects are collected that are still
reachable.

**CPython implementation detail:** CPython currently uses a reference-
counting scheme with (optional) delayed detection of cyclically linked
garbage, which collects most objects as soon as they become
unreachable, but is not guaranteed to collect garbage containing
circular references.  See the documentation of the ``gc`` module for
information on controlling the collection of cyclic garbage. Other
implementations act differently and CPython may change.

Note that the use of the implementation's tracing or debugging
facilities may keep objects alive that would normally be collectable.
Also note that catching an exception with a '``try``...``except``'
statement may keep objects alive.

Some objects contain references to "external" resources such as open
files or windows.  It is understood that these resources are freed
when the object is garbage-collected, but since garbage collection is
not guaranteed to happen, such objects also provide an explicit way to
release the external resource, usually a ``close()`` method. Programs
are strongly recommended to explicitly close such objects.  The
'``try``...``finally``' statement and the '``with``' statement provide
convenient ways to do this.

Some objects contain references to other objects; these are called
*containers*. Examples of containers are tuples, lists and
dictionaries.  The references are part of a container's value.  In
most cases, when we talk about the value of a container, we imply the
values, not the identities of the contained objects; however, when we
talk about the mutability of a container, only the identities of the
immediately contained objects are implied.  So, if an immutable
container (like a tuple) contains a reference to a mutable object, its
value changes if that mutable object is changed.

Types affect almost all aspects of object behavior.  Even the
importance of object identity is affected in some sense: for immutable
types, operations that compute new values may actually return a
reference to any existing object with the same type and value, while
for mutable objects this is not allowed.  E.g., after ``a = 1; b =
1``, ``a`` and ``b`` may or may not refer to the same object with the
value one, depending on the implementation, but after ``c = []; d =
[]``, ``c`` and ``d`` are guaranteed to refer to two different,
unique, newly created empty lists. (Note that ``c = d = []`` assigns
the same object to both ``c`` and ``d``.)


The standard type hierarchy
===========================

Below is a list of the types that are built into Python.  Extension
modules (written in C, Java, or other languages, depending on the
implementation) can define additional types.  Future versions of
Python may add types to the type hierarchy (e.g., rational numbers,
efficiently stored arrays of integers, etc.), although such additions
will often be provided via the standard library instead.

Some of the type descriptions below contain a paragraph listing
'special attributes.'  These are attributes that provide access to the
implementation and are not intended for general use.  Their definition
may change in the future.

None
   This type has a single value.  There is a single object with this
   value. This object is accessed through the built-in name ``None``.
   It is used to signify the absence of a value in many situations,
   e.g., it is returned from functions that don't explicitly return
   anything. Its truth value is false.

NotImplemented
   This type has a single value.  There is a single object with this
   value. This object is accessed through the built-in name
   ``NotImplemented``. Numeric methods and rich comparison methods may
   return this value if they do not implement the operation for the
   operands provided.  (The interpreter will then try the reflected
   operation, or some other fallback, depending on the operator.)  Its
   truth value is true.

Ellipsis
   This type has a single value.  There is a single object with this
   value. This object is accessed through the literal ``...`` or the
   built-in name ``Ellipsis``.  Its truth value is true.

``numbers.Number``
   These are created by numeric literals and returned as results by
   arithmetic operators and arithmetic built-in functions.  Numeric
   objects are immutable; once created their value never changes.
   Python numbers are of course strongly related to mathematical
   numbers, but subject to the limitations of numerical representation
   in computers.

   Python distinguishes between integers, floating point numbers, and
   complex numbers:

   ``numbers.Integral``
      These represent elements from the mathematical set of integers
      (positive and negative).

      There are two types of integers:

      Integers (``int``)

         These represent numbers in an unlimited range, subject to
         available (virtual) memory only.  For the purpose of shift
         and mask operations, a binary representation is assumed, and
         negative numbers are represented in a variant of 2's
         complement which gives the illusion of an infinite string of
         sign bits extending to the left.

      Booleans (``bool``)
         These represent the truth values False and True.  The two
         objects representing the values False and True are the only
         Boolean objects. The Boolean type is a subtype of the integer
         type, and Boolean values behave like the values 0 and 1,
         respectively, in almost all contexts, the exception being
         that when converted to a string, the strings ``"False"`` or
         ``"True"`` are returned, respectively.

      The rules for integer representation are intended to give the
      most meaningful interpretation of shift and mask operations
      involving negative integers.

   ``numbers.Real`` (``float``)
      These represent machine-level double precision floating point
      numbers. You are at the mercy of the underlying machine
      architecture (and C or Java implementation) for the accepted
      range and handling of overflow. Python does not support single-
      precision floating point numbers; the savings in processor and
      memory usage that are usually the reason for using these is
      dwarfed by the overhead of using objects in Python, so there is
      no reason to complicate the language with two kinds of floating
      point numbers.

   ``numbers.Complex`` (``complex``)
      These represent complex numbers as a pair of machine-level
      double precision floating point numbers.  The same caveats apply
      as for floating point numbers. The real and imaginary parts of a
      complex number ``z`` can be retrieved through the read-only
      attributes ``z.real`` and ``z.imag``.

Sequences
   These represent finite ordered sets indexed by non-negative
   numbers. The built-in function ``len()`` returns the number of
   items of a sequence. When the length of a sequence is *n*, the
   index set contains the numbers 0, 1, ..., *n*-1.  Item *i* of
   sequence *a* is selected by ``a[i]``.

   Sequences also support slicing: ``a[i:j]`` selects all items with
   index *k* such that *i* ``<=`` *k* ``<`` *j*.  When used as an
   expression, a slice is a sequence of the same type.  This implies
   that the index set is renumbered so that it starts at 0.

   Some sequences also support "extended slicing" with a third "step"
   parameter: ``a[i:j:k]`` selects all items of *a* with index *x*
   where ``x = i + n*k``, *n* ``>=`` ``0`` and *i* ``<=`` *x* ``<``
   *j*.

   Sequences are distinguished according to their mutability:

   Immutable sequences
      An object of an immutable sequence type cannot change once it is
      created.  (If the object contains references to other objects,
      these other objects may be mutable and may be changed; however,
      the collection of objects directly referenced by an immutable
      object cannot change.)

      The following types are immutable sequences:

      Strings
         The items of a string object are Unicode code units.  A
         Unicode code unit is represented by a string object of one
         item and can hold either a 16-bit or 32-bit value
         representing a Unicode ordinal (the maximum value for the
         ordinal is given in ``sys.maxunicode``, and depends on how
         Python is configured at compile time).  Surrogate pairs may
         be present in the Unicode object, and will be reported as two
         separate items.  The built-in functions ``chr()`` and
         ``ord()`` convert between code units and nonnegative integers
         representing the Unicode ordinals as defined in the Unicode
         Standard 3.0. Conversion from and to other encodings are
         possible through the string method ``encode()``.

      Tuples
         The items of a tuple are arbitrary Python objects. Tuples of
         two or more items are formed by comma-separated lists of
         expressions.  A tuple of one item (a 'singleton') can be
         formed by affixing a comma to an expression (an expression by
         itself does not create a tuple, since parentheses must be
         usable for grouping of expressions).  An empty tuple can be
         formed by an empty pair of parentheses.

      Bytes
         A bytes object is an immutable array.  The items are 8-bit
         bytes, represented by integers in the range 0 <= x < 256.
         Bytes literals (like ``b'abc'`` and the built-in function
         ``bytes()`` can be used to construct bytes objects.  Also,
         bytes objects can be decoded to strings via the ``decode()``
         method.

   Mutable sequences
      Mutable sequences can be changed after they are created.  The
      subscription and slicing notations can be used as the target of
      assignment and ``del`` (delete) statements.

      There are currently two intrinsic mutable sequence types:

      Lists
         The items of a list are arbitrary Python objects.  Lists are
         formed by placing a comma-separated list of expressions in
         square brackets. (Note that there are no special cases needed
         to form lists of length 0 or 1.)

      Byte Arrays
         A bytearray object is a mutable array. They are created by
         the built-in ``bytearray()`` constructor.  Aside from being
         mutable (and hence unhashable), byte arrays otherwise provide
         the same interface and functionality as immutable bytes
         objects.

      The extension module ``array`` provides an additional example of
      a mutable sequence type, as does the ``collections`` module.

Set types
   These represent unordered, finite sets of unique, immutable
   objects. As such, they cannot be indexed by any subscript. However,
   they can be iterated over, and the built-in function ``len()``
   returns the number of items in a set. Common uses for sets are fast
   membership testing, removing duplicates from a sequence, and
   computing mathematical operations such as intersection, union,
   difference, and symmetric difference.

   For set elements, the same immutability rules apply as for
   dictionary keys. Note that numeric types obey the normal rules for
   numeric comparison: if two numbers compare equal (e.g., ``1`` and
   ``1.0``), only one of them can be contained in a set.

   There are currently two intrinsic set types:

   Sets
      These represent a mutable set. They are created by the built-in
      ``set()`` constructor and can be modified afterwards by several
      methods, such as ``add()``.

   Frozen sets
      These represent an immutable set.  They are created by the
      built-in ``frozenset()`` constructor.  As a frozenset is
      immutable and *hashable*, it can be used again as an element of
      another set, or as a dictionary key.

Mappings
   These represent finite sets of objects indexed by arbitrary index
   sets. The subscript notation ``a[k]`` selects the item indexed by
   ``k`` from the mapping ``a``; this can be used in expressions and
   as the target of assignments or ``del`` statements. The built-in
   function ``len()`` returns the number of items in a mapping.

   There is currently a single intrinsic mapping type:

   Dictionaries
      These represent finite sets of objects indexed by nearly
      arbitrary values.  The only types of values not acceptable as
      keys are values containing lists or dictionaries or other
      mutable types that are compared by value rather than by object
      identity, the reason being that the efficient implementation of
      dictionaries requires a key's hash value to remain constant.
      Numeric types used for keys obey the normal rules for numeric
      comparison: if two numbers compare equal (e.g., ``1`` and
      ``1.0``) then they can be used interchangeably to index the same
      dictionary entry.

      Dictionaries are mutable; they can be created by the ``{...}``
      notation (see section *Dictionary displays*).

      The extension modules ``dbm.ndbm`` and ``dbm.gnu`` provide
      additional examples of mapping types, as does the
      ``collections`` module.

Callable types
   These are the types to which the function call operation (see
   section *Calls*) can be applied:

   User-defined functions
      A user-defined function object is created by a function
      definition (see section *Function definitions*).  It should be
      called with an argument list containing the same number of items
      as the function's formal parameter list.

      Special attributes:

      +---------------------------+---------------------------------+-------------+
      | Attribute                 | Meaning                         |             |
      +===========================+=================================+=============+
      | ``__doc__``               | The function's documentation    | Writable    |
      |                           | string, or ``None`` if          |             |
      |                           | unavailable                     |             |
      +---------------------------+---------------------------------+-------------+
      | ``__name__``              | The function's name             | Writable    |
      +---------------------------+---------------------------------+-------------+
      | ``__module__``            | The name of the module the      | Writable    |
      |                           | function was defined in, or     |             |
      |                           | ``None`` if unavailable.        |             |
      +---------------------------+---------------------------------+-------------+
      | ``__defaults__``          | A tuple containing default      | Writable    |
      |                           | argument values for those       |             |
      |                           | arguments that have defaults,   |             |
      |                           | or ``None`` if no arguments     |             |
      |                           | have a default value            |             |
      +---------------------------+---------------------------------+-------------+
      | ``__code__``              | The code object representing    | Writable    |
      |                           | the compiled function body.     |             |
      +---------------------------+---------------------------------+-------------+
      | ``__globals__``           | A reference to the dictionary   | Read-only   |
      |                           | that holds the function's       |             |
      |                           | global variables --- the global |             |
      |                           | namespace of the module in      |             |
      |                           | which the function was defined. |             |
      +---------------------------+---------------------------------+-------------+
      | ``__dict__``              | The namespace supporting        | Writable    |
      |                           | arbitrary function attributes.  |             |
      +---------------------------+---------------------------------+-------------+
      | ``__closure__``           | ``None`` or a tuple of cells    | Read-only   |
      |                           | that contain bindings for the   |             |
      |                           | function's free variables.      |             |
      +---------------------------+---------------------------------+-------------+
      | ``__annotations__``       | A dict containing annotations   | Writable    |
      |                           | of parameters.  The keys of the |             |
      |                           | dict are the parameter names,   |             |
      |                           | or ``'return'`` for the return  |             |
      |                           | annotation, if provided.        |             |
      +---------------------------+---------------------------------+-------------+
      | ``__kwdefaults__``        | A dict containing defaults for  | Writable    |
      |                           | keyword-only parameters.        |             |
      +---------------------------+---------------------------------+-------------+

      Most of the attributes labelled "Writable" check the type of the
      assigned value.

      Function objects also support getting and setting arbitrary
      attributes, which can be used, for example, to attach metadata
      to functions.  Regular attribute dot-notation is used to get and
      set such attributes. *Note that the current implementation only
      supports function attributes on user-defined functions. Function
      attributes on built-in functions may be supported in the
      future.*

      Additional information about a function's definition can be
      retrieved from its code object; see the description of internal
      types below.

   Instance methods
      An instance method object combines a class, a class instance and
      any callable object (normally a user-defined function).

      Special read-only attributes: ``__self__`` is the class instance
      object, ``__func__`` is the function object; ``__doc__`` is the
      method's documentation (same as ``__func__.__doc__``);
      ``__name__`` is the method name (same as ``__func__.__name__``);
      ``__module__`` is the name of the module the method was defined
      in, or ``None`` if unavailable.

      Methods also support accessing (but not setting) the arbitrary
      function attributes on the underlying function object.

      User-defined method objects may be created when getting an
      attribute of a class (perhaps via an instance of that class), if
      that attribute is a user-defined function object or a class
      method object.

      When an instance method object is created by retrieving a user-
      defined function object from a class via one of its instances,
      its ``__self__`` attribute is the instance, and the method
      object is said to be bound.  The new method's ``__func__``
      attribute is the original function object.

      When a user-defined method object is created by retrieving
      another method object from a class or instance, the behaviour is
      the same as for a function object, except that the ``__func__``
      attribute of the new instance is not the original method object
      but its ``__func__`` attribute.

      When an instance method object is created by retrieving a class
      method object from a class or instance, its ``__self__``
      attribute is the class itself, and its ``__func__`` attribute is
      the function object underlying the class method.

      When an instance method object is called, the underlying
      function (``__func__``) is called, inserting the class instance
      (``__self__``) in front of the argument list.  For instance,
      when ``C`` is a class which contains a definition for a function
      ``f()``, and ``x`` is an instance of ``C``, calling ``x.f(1)``
      is equivalent to calling ``C.f(x, 1)``.

      When an instance method object is derived from a class method
      object, the "class instance" stored in ``__self__`` will
      actually be the class itself, so that calling either ``x.f(1)``
      or ``C.f(1)`` is equivalent to calling ``f(C,1)`` where ``f`` is
      the underlying function.

      Note that the transformation from function object to instance
      method object happens each time the attribute is retrieved from
      the instance.  In some cases, a fruitful optimization is to
      assign the attribute to a local variable and call that local
      variable. Also notice that this transformation only happens for
      user-defined functions; other callable objects (and all non-
      callable objects) are retrieved without transformation.  It is
      also important to note that user-defined functions which are
      attributes of a class instance are not converted to bound
      methods; this *only* happens when the function is an attribute
      of the class.

   Generator functions
      A function or method which uses the ``yield`` statement (see
      section *The yield statement*) is called a *generator function*.
      Such a function, when called, always returns an iterator object
      which can be used to execute the body of the function:  calling
      the iterator's ``__next__()`` method will cause the function to
      execute until it provides a value using the ``yield`` statement.
      When the function executes a ``return`` statement or falls off
      the end, a ``StopIteration`` exception is raised and the
      iterator will have reached the end of the set of values to be
      returned.

   Built-in functions
      A built-in function object is a wrapper around a C function.
      Examples of built-in functions are ``len()`` and ``math.sin()``
      (``math`` is a standard built-in module). The number and type of
      the arguments are determined by the C function. Special read-
      only attributes: ``__doc__`` is the function's documentation
      string, or ``None`` if unavailable; ``__name__`` is the
      function's name; ``__self__`` is set to ``None`` (but see the
      next item); ``__module__`` is the name of the module the
      function was defined in or ``None`` if unavailable.

   Built-in methods
      This is really a different disguise of a built-in function, this
      time containing an object passed to the C function as an
      implicit extra argument.  An example of a built-in method is
      ``alist.append()``, assuming *alist* is a list object. In this
      case, the special read-only attribute ``__self__`` is set to the
      object denoted by *alist*.

   Classes
      Classes are callable.  These objects normally act as factories
      for new instances of themselves, but variations are possible for
      class types that override ``__new__()``.  The arguments of the
      call are passed to ``__new__()`` and, in the typical case, to
      ``__init__()`` to initialize the new instance.

   Class Instances
      Instances of arbitrary classes can be made callable by defining
      a ``__call__()`` method in their class.

Modules
   Modules are imported by the ``import`` statement (see section *The
   import statement*). A module object has a namespace implemented by
   a dictionary object (this is the dictionary referenced by the
   __globals__ attribute of functions defined in the module).
   Attribute references are translated to lookups in this dictionary,
   e.g., ``m.x`` is equivalent to ``m.__dict__["x"]``. A module object
   does not contain the code object used to initialize the module
   (since it isn't needed once the initialization is done).

   Attribute assignment updates the module's namespace dictionary,
   e.g., ``m.x = 1`` is equivalent to ``m.__dict__["x"] = 1``.

   Special read-only attribute: ``__dict__`` is the module's namespace
   as a dictionary object.

   **CPython implementation detail:** Because of the way CPython
   clears module dictionaries, the module dictionary will be cleared
   when the module falls out of scope even if the dictionary still has
   live references.  To avoid this, copy the dictionary or keep the
   module around while using its dictionary directly.

   Predefined (writable) attributes: ``__name__`` is the module's
   name; ``__doc__`` is the module's documentation string, or ``None``
   if unavailable; ``__file__`` is the pathname of the file from which
   the module was loaded, if it was loaded from a file. The
   ``__file__`` attribute is not present for C modules that are
   statically linked into the interpreter; for extension modules
   loaded dynamically from a shared library, it is the pathname of the
   shared library file.

Custom classes
   Custom class types are typically created by class definitions (see
   section *Class definitions*).  A class has a namespace implemented
   by a dictionary object. Class attribute references are translated
   to lookups in this dictionary, e.g., ``C.x`` is translated to
   ``C.__dict__["x"]`` (although there are a number of hooks which
   allow for other means of locating attributes). When the attribute
   name is not found there, the attribute search continues in the base
   classes. This search of the base classes uses the C3 method
   resolution order which behaves correctly even in the presence of
   'diamond' inheritance structures where there are multiple
   inheritance paths leading back to a common ancestor. Additional
   details on the C3 MRO used by Python can be found in the
   documentation accompanying the 2.3 release at
   http://www.python.org/download/releases/2.3/mro/.

   When a class attribute reference (for class ``C``, say) would yield
   a class method object, it is transformed into an instance method
   object whose ``__self__`` attributes is ``C``.  When it would yield
   a static method object, it is transformed into the object wrapped
   by the static method object. See section *Implementing Descriptors*
   for another way in which attributes retrieved from a class may
   differ from those actually contained in its ``__dict__``.

   Class attribute assignments update the class's dictionary, never
   the dictionary of a base class.

   A class object can be called (see above) to yield a class instance
   (see below).

   Special attributes: ``__name__`` is the class name; ``__module__``
   is the module name in which the class was defined; ``__dict__`` is
   the dictionary containing the class's namespace; ``__bases__`` is a
   tuple (possibly empty or a singleton) containing the base classes,
   in the order of their occurrence in the base class list;
   ``__doc__`` is the class's documentation string, or None if
   undefined.

Class instances
   A class instance is created by calling a class object (see above).
   A class instance has a namespace implemented as a dictionary which
   is the first place in which attribute references are searched.
   When an attribute is not found there, and the instance's class has
   an attribute by that name, the search continues with the class
   attributes.  If a class attribute is found that is a user-defined
   function object, it is transformed into an instance method object
   whose ``__self__`` attribute is the instance.  Static method and
   class method objects are also transformed; see above under
   "Classes".  See section *Implementing Descriptors* for another way
   in which attributes of a class retrieved via its instances may
   differ from the objects actually stored in the class's
   ``__dict__``.  If no class attribute is found, and the object's
   class has a ``__getattr__()`` method, that is called to satisfy the
   lookup.

   Attribute assignments and deletions update the instance's
   dictionary, never a class's dictionary.  If the class has a
   ``__setattr__()`` or ``__delattr__()`` method, this is called
   instead of updating the instance dictionary directly.

   Class instances can pretend to be numbers, sequences, or mappings
   if they have methods with certain special names.  See section
   *Special method names*.

   Special attributes: ``__dict__`` is the attribute dictionary;
   ``__class__`` is the instance's class.

I/O objects (also known as file objects)
   A *file object* represents an open file.  Various shortcuts are
   available to create file objects: the ``open()`` built-in function,
   and also ``os.popen()``, ``os.fdopen()``, and the ``makefile()``
   method of socket objects (and perhaps by other functions or methods
   provided by extension modules).

   The objects ``sys.stdin``, ``sys.stdout`` and ``sys.stderr`` are
   initialized to file objects corresponding to the interpreter's
   standard input, output and error streams; they are all open in text
   mode and therefore follow the interface defined by the
   ``io.TextIOBase`` abstract class.

Internal types
   A few types used internally by the interpreter are exposed to the
   user. Their definitions may change with future versions of the
   interpreter, but they are mentioned here for completeness.

   Code objects
      Code objects represent *byte-compiled* executable Python code,
      or *bytecode*. The difference between a code object and a
      function object is that the function object contains an explicit
      reference to the function's globals (the module in which it was
      defined), while a code object contains no context; also the
      default argument values are stored in the function object, not
      in the code object (because they represent values calculated at
      run-time).  Unlike function objects, code objects are immutable
      and contain no references (directly or indirectly) to mutable
      objects.

      Special read-only attributes: ``co_name`` gives the function
      name; ``co_argcount`` is the number of positional arguments
      (including arguments with default values); ``co_nlocals`` is the
      number of local variables used by the function (including
      arguments); ``co_varnames`` is a tuple containing the names of
      the local variables (starting with the argument names);
      ``co_cellvars`` is a tuple containing the names of local
      variables that are referenced by nested functions;
      ``co_freevars`` is a tuple containing the names of free
      variables; ``co_code`` is a string representing the sequence of
      bytecode instructions; ``co_consts`` is a tuple containing the
      literals used by the bytecode; ``co_names`` is a tuple
      containing the names used by the bytecode; ``co_filename`` is
      the filename from which the code was compiled;
      ``co_firstlineno`` is the first line number of the function;
      ``co_lnotab`` is a string encoding the mapping from bytecode
      offsets to line numbers (for details see the source code of the
      interpreter); ``co_stacksize`` is the required stack size
      (including local variables); ``co_flags`` is an integer encoding
      a number of flags for the interpreter.

      The following flag bits are defined for ``co_flags``: bit
      ``0x04`` is set if the function uses the ``*arguments`` syntax
      to accept an arbitrary number of positional arguments; bit
      ``0x08`` is set if the function uses the ``**keywords`` syntax
      to accept arbitrary keyword arguments; bit ``0x20`` is set if
      the function is a generator.

      Future feature declarations (``from __future__ import
      division``) also use bits in ``co_flags`` to indicate whether a
      code object was compiled with a particular feature enabled: bit
      ``0x2000`` is set if the function was compiled with future
      division enabled; bits ``0x10`` and ``0x1000`` were used in
      earlier versions of Python.

      Other bits in ``co_flags`` are reserved for internal use.

      If a code object represents a function, the first item in
      ``co_consts`` is the documentation string of the function, or
      ``None`` if undefined.

   Frame objects
      Frame objects represent execution frames.  They may occur in
      traceback objects (see below).

      Special read-only attributes: ``f_back`` is to the previous
      stack frame (towards the caller), or ``None`` if this is the
      bottom stack frame; ``f_code`` is the code object being executed
      in this frame; ``f_locals`` is the dictionary used to look up
      local variables; ``f_globals`` is used for global variables;
      ``f_builtins`` is used for built-in (intrinsic) names;
      ``f_lasti`` gives the precise instruction (this is an index into
      the bytecode string of the code object).

      Special writable attributes: ``f_trace``, if not ``None``, is a
      function called at the start of each source code line (this is
      used by the debugger); ``f_lineno`` is the current line number
      of the frame --- writing to this from within a trace function
      jumps to the given line (only for the bottom-most frame).  A
      debugger can implement a Jump command (aka Set Next Statement)
      by writing to f_lineno.

   Traceback objects
      Traceback objects represent a stack trace of an exception.  A
      traceback object is created when an exception occurs.  When the
      search for an exception handler unwinds the execution stack, at
      each unwound level a traceback object is inserted in front of
      the current traceback.  When an exception handler is entered,
      the stack trace is made available to the program. (See section
      *The try statement*.) It is accessible as the third item of the
      tuple returned by ``sys.exc_info()``. When the program contains
      no suitable handler, the stack trace is written (nicely
      formatted) to the standard error stream; if the interpreter is
      interactive, it is also made available to the user as
      ``sys.last_traceback``.

      Special read-only attributes: ``tb_next`` is the next level in
      the stack trace (towards the frame where the exception
      occurred), or ``None`` if there is no next level; ``tb_frame``
      points to the execution frame of the current level;
      ``tb_lineno`` gives the line number where the exception
      occurred; ``tb_lasti`` indicates the precise instruction.  The
      line number and last instruction in the traceback may differ
      from the line number of its frame object if the exception
      occurred in a ``try`` statement with no matching except clause
      or with a finally clause.

   Slice objects
      Slice objects are used to represent slices for ``__getitem__()``
      methods.  They are also created by the built-in ``slice()``
      function.

      Special read-only attributes: ``start`` is the lower bound;
      ``stop`` is the upper bound; ``step`` is the step value; each is
      ``None`` if omitted. These attributes can have any type.

      Slice objects support one method:

      slice.indices(self, length)

         This method takes a single integer argument *length* and
         computes information about the slice that the slice object
         would describe if applied to a sequence of *length* items.
         It returns a tuple of three integers; respectively these are
         the *start* and *stop* indices and the *step* or stride
         length of the slice. Missing or out-of-bounds indices are
         handled in a manner consistent with regular slices.

   Static method objects
      Static method objects provide a way of defeating the
      transformation of function objects to method objects described
      above. A static method object is a wrapper around any other
      object, usually a user-defined method object. When a static
      method object is retrieved from a class or a class instance, the
      object actually returned is the wrapped object, which is not
      subject to any further transformation. Static method objects are
      not themselves callable, although the objects they wrap usually
      are. Static method objects are created by the built-in
      ``staticmethod()`` constructor.

   Class method objects
      A class method object, like a static method object, is a wrapper
      around another object that alters the way in which that object
      is retrieved from classes and class instances. The behaviour of
      class method objects upon such retrieval is described above,
      under "User-defined methods". Class method objects are created
      by the built-in ``classmethod()`` constructor.


Special method names
====================

A class can implement certain operations that are invoked by special
syntax (such as arithmetic operations or subscripting and slicing) by
defining methods with special names. This is Python's approach to
*operator overloading*, allowing classes to define their own behavior
with respect to language operators.  For instance, if a class defines
a method named ``__getitem__()``, and ``x`` is an instance of this
class, then ``x[i]`` is roughly equivalent to ``type(x).__getitem__(x,
i)``.  Except where mentioned, attempts to execute an operation raise
an exception when no appropriate method is defined (typically
``AttributeError`` or ``TypeError``).

When implementing a class that emulates any built-in type, it is
important that the emulation only be implemented to the degree that it
makes sense for the object being modelled.  For example, some
sequences may work well with retrieval of individual elements, but
extracting a slice may not make sense.  (One example of this is the
``NodeList`` interface in the W3C's Document Object Model.)


Basic customization
-------------------

object.__new__(cls[, ...])

   Called to create a new instance of class *cls*.  ``__new__()`` is a
   static method (special-cased so you need not declare it as such)
   that takes the class of which an instance was requested as its
   first argument.  The remaining arguments are those passed to the
   object constructor expression (the call to the class).  The return
   value of ``__new__()`` should be the new object instance (usually
   an instance of *cls*).

   Typical implementations create a new instance of the class by
   invoking the superclass's ``__new__()`` method using
   ``super(currentclass, cls).__new__(cls[, ...])`` with appropriate
   arguments and then modifying the newly-created instance as
   necessary before returning it.

   If ``__new__()`` returns an instance of *cls*, then the new
   instance's ``__init__()`` method will be invoked like
   ``__init__(self[, ...])``, where *self* is the new instance and the
   remaining arguments are the same as were passed to ``__new__()``.

   If ``__new__()`` does not return an instance of *cls*, then the new
   instance's ``__init__()`` method will not be invoked.

   ``__new__()`` is intended mainly to allow subclasses of immutable
   types (like int, str, or tuple) to customize instance creation.  It
   is also commonly overridden in custom metaclasses in order to
   customize class creation.

object.__init__(self[, ...])

   Called when the instance is created.  The arguments are those
   passed to the class constructor expression.  If a base class has an
   ``__init__()`` method, the derived class's ``__init__()`` method,
   if any, must explicitly call it to ensure proper initialization of
   the base class part of the instance; for example:
   ``BaseClass.__init__(self, [args...])``.  As a special constraint
   on constructors, no value may be returned; doing so will cause a
   ``TypeError`` to be raised at runtime.

object.__del__(self)

   Called when the instance is about to be destroyed.  This is also
   called a destructor.  If a base class has a ``__del__()`` method,
   the derived class's ``__del__()`` method, if any, must explicitly
   call it to ensure proper deletion of the base class part of the
   instance.  Note that it is possible (though not recommended!) for
   the ``__del__()`` method to postpone destruction of the instance by
   creating a new reference to it.  It may then be called at a later
   time when this new reference is deleted.  It is not guaranteed that
   ``__del__()`` methods are called for objects that still exist when
   the interpreter exits.

   Note: ``del x`` doesn't directly call ``x.__del__()`` --- the former
     decrements the reference count for ``x`` by one, and the latter
     is only called when ``x``'s reference count reaches zero.  Some
     common situations that may prevent the reference count of an
     object from going to zero include: circular references between
     objects (e.g., a doubly-linked list or a tree data structure with
     parent and child pointers); a reference to the object on the
     stack frame of a function that caught an exception (the traceback
     stored in ``sys.exc_info()[2]`` keeps the stack frame alive); or
     a reference to the object on the stack frame that raised an
     unhandled exception in interactive mode (the traceback stored in
     ``sys.last_traceback`` keeps the stack frame alive).  The first
     situation can only be remedied by explicitly breaking the cycles;
     the latter two situations can be resolved by storing ``None`` in
     ``sys.last_traceback``. Circular references which are garbage are
     detected when the option cycle detector is enabled (it's on by
     default), but can only be cleaned up if there are no Python-
     level ``__del__()`` methods involved. Refer to the documentation
     for the ``gc`` module for more information about how
     ``__del__()`` methods are handled by the cycle detector,
     particularly the description of the ``garbage`` value.

   Warning: Due to the precarious circumstances under which ``__del__()``
     methods are invoked, exceptions that occur during their execution
     are ignored, and a warning is printed to ``sys.stderr`` instead.
     Also, when ``__del__()`` is invoked in response to a module being
     deleted (e.g., when execution of the program is done), other
     globals referenced by the ``__del__()`` method may already have
     been deleted or in the process of being torn down (e.g. the
     import machinery shutting down).  For this reason, ``__del__()``
     methods should do the absolute minimum needed to maintain
     external invariants.  Starting with version 1.5, Python
     guarantees that globals whose name begins with a single
     underscore are deleted from their module before other globals are
     deleted; if no other references to such globals exist, this may
     help in assuring that imported modules are still available at the
     time when the ``__del__()`` method is called.

object.__repr__(self)

   Called by the ``repr()`` built-in function to compute the
   "official" string representation of an object.  If at all possible,
   this should look like a valid Python expression that could be used
   to recreate an object with the same value (given an appropriate
   environment).  If this is not possible, a string of the form
   ``<...some useful description...>`` should be returned. The return
   value must be a string object. If a class defines ``__repr__()``
   but not ``__str__()``, then ``__repr__()`` is also used when an
   "informal" string representation of instances of that class is
   required.

   This is typically used for debugging, so it is important that the
   representation is information-rich and unambiguous.

object.__str__(self)

   Called by the ``str()`` built-in function and by the ``print()``
   function to compute the "informal" string representation of an
   object.  This differs from ``__repr__()`` in that it does not have
   to be a valid Python expression: a more convenient or concise
   representation may be used instead. The return value must be a
   string object.

object.__format__(self, format_spec)

   Called by the ``format()`` built-in function (and by extension, the
   ``format()`` method of class ``str``) to produce a "formatted"
   string representation of an object. The ``format_spec`` argument is
   a string that contains a description of the formatting options
   desired. The interpretation of the ``format_spec`` argument is up
   to the type implementing ``__format__()``, however most classes
   will either delegate formatting to one of the built-in types, or
   use a similar formatting option syntax.

   See *Format Specification Mini-Language* for a description of the
   standard formatting syntax.

   The return value must be a string object.

object.__lt__(self, other)
object.__le__(self, other)
object.__eq__(self, other)
object.__ne__(self, other)
object.__gt__(self, other)
object.__ge__(self, other)

   These are the so-called "rich comparison" methods. The
   correspondence between operator symbols and method names is as
   follows: ``x<y`` calls ``x.__lt__(y)``, ``x<=y`` calls
   ``x.__le__(y)``, ``x==y`` calls ``x.__eq__(y)``, ``x!=y`` calls
   ``x.__ne__(y)``, ``x>y`` calls ``x.__gt__(y)``, and ``x>=y`` calls
   ``x.__ge__(y)``.

   A rich comparison method may return the singleton
   ``NotImplemented`` if it does not implement the operation for a
   given pair of arguments. By convention, ``False`` and ``True`` are
   returned for a successful comparison. However, these methods can
   return any value, so if the comparison operator is used in a
   Boolean context (e.g., in the condition of an ``if`` statement),
   Python will call ``bool()`` on the value to determine if the result
   is true or false.

   There are no implied relationships among the comparison operators.
   The truth of ``x==y`` does not imply that ``x!=y`` is false.
   Accordingly, when defining ``__eq__()``, one should also define
   ``__ne__()`` so that the operators will behave as expected.  See
   the paragraph on ``__hash__()`` for some important notes on
   creating *hashable* objects which support custom comparison
   operations and are usable as dictionary keys.

   There are no swapped-argument versions of these methods (to be used
   when the left argument does not support the operation but the right
   argument does); rather, ``__lt__()`` and ``__gt__()`` are each
   other's reflection, ``__le__()`` and ``__ge__()`` are each other's
   reflection, and ``__eq__()`` and ``__ne__()`` are their own
   reflection.

   Arguments to rich comparison methods are never coerced.

   To automatically generate ordering operations from a single root
   operation, see ``functools.total_ordering()``.

object.__hash__(self)

   Called by built-in function ``hash()`` and for operations on
   members of hashed collections including ``set``, ``frozenset``, and
   ``dict``.  ``__hash__()`` should return an integer.  The only
   required property is that objects which compare equal have the same
   hash value; it is advised to somehow mix together (e.g. using
   exclusive or) the hash values for the components of the object that
   also play a part in comparison of objects.

   If a class does not define an ``__eq__()`` method it should not
   define a ``__hash__()`` operation either; if it defines
   ``__eq__()`` but not ``__hash__()``, its instances will not be
   usable as items in hashable collections.  If a class defines
   mutable objects and implements an ``__eq__()`` method, it should
   not implement ``__hash__()``, since the implementation of hashable
   collections requires that a key's hash value is immutable (if the
   object's hash value changes, it will be in the wrong hash bucket).

   User-defined classes have ``__eq__()`` and ``__hash__()`` methods
   by default; with them, all objects compare unequal (except with
   themselves) and ``x.__hash__()`` returns ``id(x)``.

   Classes which inherit a ``__hash__()`` method from a parent class
   but change the meaning of ``__eq__()`` such that the hash value
   returned is no longer appropriate (e.g. by switching to a value-
   based concept of equality instead of the default identity based
   equality) can explicitly flag themselves as being unhashable by
   setting ``__hash__ = None`` in the class definition. Doing so means
   that not only will instances of the class raise an appropriate
   ``TypeError`` when a program attempts to retrieve their hash value,
   but they will also be correctly identified as unhashable when
   checking ``isinstance(obj, collections.Hashable)`` (unlike classes
   which define their own ``__hash__()`` to explicitly raise
   ``TypeError``).

   If a class that overrides ``__eq__()`` needs to retain the
   implementation of ``__hash__()`` from a parent class, the
   interpreter must be told this explicitly by setting ``__hash__ =
   <ParentClass>.__hash__``. Otherwise the inheritance of
   ``__hash__()`` will be blocked, just as if ``__hash__`` had been
   explicitly set to ``None``.

object.__bool__(self)

   Called to implement truth value testing and the built-in operation
   ``bool()``; should return ``False`` or ``True``.  When this method
   is not defined, ``__len__()`` is called, if it is defined, and the
   object is considered true if its result is nonzero.  If a class
   defines neither ``__len__()`` nor ``__bool__()``, all its instances
   are considered true.


Customizing attribute access
----------------------------

The following methods can be defined to customize the meaning of
attribute access (use of, assignment to, or deletion of ``x.name``)
for class instances.

object.__getattr__(self, name)

   Called when an attribute lookup has not found the attribute in the
   usual places (i.e. it is not an instance attribute nor is it found
   in the class tree for ``self``).  ``name`` is the attribute name.
   This method should return the (computed) attribute value or raise
   an ``AttributeError`` exception.

   Note that if the attribute is found through the normal mechanism,
   ``__getattr__()`` is not called.  (This is an intentional asymmetry
   between ``__getattr__()`` and ``__setattr__()``.) This is done both
   for efficiency reasons and because otherwise ``__getattr__()``
   would have no way to access other attributes of the instance.  Note
   that at least for instance variables, you can fake total control by
   not inserting any values in the instance attribute dictionary (but
   instead inserting them in another object).  See the
   ``__getattribute__()`` method below for a way to actually get total
   control over attribute access.

object.__getattribute__(self, name)

   Called unconditionally to implement attribute accesses for
   instances of the class. If the class also defines
   ``__getattr__()``, the latter will not be called unless
   ``__getattribute__()`` either calls it explicitly or raises an
   ``AttributeError``. This method should return the (computed)
   attribute value or raise an ``AttributeError`` exception. In order
   to avoid infinite recursion in this method, its implementation
   should always call the base class method with the same name to
   access any attributes it needs, for example,
   ``object.__getattribute__(self, name)``.

   Note: This method may still be bypassed when looking up special methods
     as the result of implicit invocation via language syntax or
     built-in functions. See *Special method lookup*.

object.__setattr__(self, name, value)

   Called when an attribute assignment is attempted.  This is called
   instead of the normal mechanism (i.e. store the value in the
   instance dictionary). *name* is the attribute name, *value* is the
   value to be assigned to it.

   If ``__setattr__()`` wants to assign to an instance attribute, it
   should call the base class method with the same name, for example,
   ``object.__setattr__(self, name, value)``.

object.__delattr__(self, name)

   Like ``__setattr__()`` but for attribute deletion instead of
   assignment.  This should only be implemented if ``del obj.name`` is
   meaningful for the object.

object.__dir__(self)

   Called when ``dir()`` is called on the object.  A list must be
   returned.


Implementing Descriptors
~~~~~~~~~~~~~~~~~~~~~~~~

The following methods only apply when an instance of the class
containing the method (a so-called *descriptor* class) appears in the
class dictionary of another class, known as the *owner* class.  In the
examples below, "the attribute" refers to the attribute whose name is
the key of the property in the owner class' ``__dict__``.

object.__get__(self, instance, owner)

   Called to get the attribute of the owner class (class attribute
   access) or of an instance of that class (instance attribute
   access). *owner* is always the owner class, while *instance* is the
   instance that the attribute was accessed through, or ``None`` when
   the attribute is accessed through the *owner*.  This method should
   return the (computed) attribute value or raise an
   ``AttributeError`` exception.

object.__set__(self, instance, value)

   Called to set the attribute on an instance *instance* of the owner
   class to a new value, *value*.

object.__delete__(self, instance)

   Called to delete the attribute on an instance *instance* of the
   owner class.


Invoking Descriptors
~~~~~~~~~~~~~~~~~~~~

In general, a descriptor is an object attribute with "binding
behavior", one whose attribute access has been overridden by methods
in the descriptor protocol:  ``__get__()``, ``__set__()``, and
``__delete__()``. If any of those methods are defined for an object,
it is said to be a descriptor.

The default behavior for attribute access is to get, set, or delete
the attribute from an object's dictionary. For instance, ``a.x`` has a
lookup chain starting with ``a.__dict__['x']``, then
``type(a).__dict__['x']``, and continuing through the base classes of
``type(a)`` excluding metaclasses.

However, if the looked-up value is an object defining one of the
descriptor methods, then Python may override the default behavior and
invoke the descriptor method instead.  Where this occurs in the
precedence chain depends on which descriptor methods were defined and
how they were called.

The starting point for descriptor invocation is a binding, ``a.x``.
How the arguments are assembled depends on ``a``:

Direct Call
   The simplest and least common call is when user code directly
   invokes a descriptor method:    ``x.__get__(a)``.

Instance Binding
   If binding to an object instance, ``a.x`` is transformed into the
   call: ``type(a).__dict__['x'].__get__(a, type(a))``.

Class Binding
   If binding to a class, ``A.x`` is transformed into the call:
   ``A.__dict__['x'].__get__(None, A)``.

Super Binding
   If ``a`` is an instance of ``super``, then the binding ``super(B,
   obj).m()`` searches ``obj.__class__.__mro__`` for the base class
   ``A`` immediately preceding ``B`` and then invokes the descriptor
   with the call: ``A.__dict__['m'].__get__(obj, A)``.

For instance bindings, the precedence of descriptor invocation depends
on the which descriptor methods are defined.  A descriptor can define
any combination of ``__get__()``, ``__set__()`` and ``__delete__()``.
If it does not define ``__get__()``, then accessing the attribute will
return the descriptor object itself unless there is a value in the
object's instance dictionary.  If the descriptor defines ``__set__()``
and/or ``__delete__()``, it is a data descriptor; if it defines
neither, it is a non-data descriptor.  Normally, data descriptors
define both ``__get__()`` and ``__set__()``, while non-data
descriptors have just the ``__get__()`` method.  Data descriptors with
``__set__()`` and ``__get__()`` defined always override a redefinition
in an instance dictionary.  In contrast, non-data descriptors can be
overridden by instances.

Python methods (including ``staticmethod()`` and ``classmethod()``)
are implemented as non-data descriptors.  Accordingly, instances can
redefine and override methods.  This allows individual instances to
acquire behaviors that differ from other instances of the same class.

The ``property()`` function is implemented as a data descriptor.
Accordingly, instances cannot override the behavior of a property.


__slots__
~~~~~~~~~

By default, instances of classes have a dictionary for attribute
storage.  This wastes space for objects having very few instance
variables.  The space consumption can become acute when creating large
numbers of instances.

The default can be overridden by defining *__slots__* in a class
definition. The *__slots__* declaration takes a sequence of instance
variables and reserves just enough space in each instance to hold a
value for each variable.  Space is saved because *__dict__* is not
created for each instance.

object.__slots__

   This class variable can be assigned a string, iterable, or sequence
   of strings with variable names used by instances.  If defined in a
   class, *__slots__* reserves space for the declared variables and
   prevents the automatic creation of *__dict__* and *__weakref__* for
   each instance.


Notes on using *__slots__*
""""""""""""""""""""""""""

* When inheriting from a class without *__slots__*, the *__dict__*
  attribute of that class will always be accessible, so a *__slots__*
  definition in the subclass is meaningless.

* Without a *__dict__* variable, instances cannot be assigned new
  variables not listed in the *__slots__* definition.  Attempts to
  assign to an unlisted variable name raises ``AttributeError``. If
  dynamic assignment of new variables is desired, then add
  ``'__dict__'`` to the sequence of strings in the *__slots__*
  declaration.

* Without a *__weakref__* variable for each instance, classes defining
  *__slots__* do not support weak references to its instances. If weak
  reference support is needed, then add ``'__weakref__'`` to the
  sequence of strings in the *__slots__* declaration.

* *__slots__* are implemented at the class level by creating
  descriptors (*Implementing Descriptors*) for each variable name.  As
  a result, class attributes cannot be used to set default values for
  instance variables defined by *__slots__*; otherwise, the class
  attribute would overwrite the descriptor assignment.

* The action of a *__slots__* declaration is limited to the class
  where it is defined.  As a result, subclasses will have a *__dict__*
  unless they also define *__slots__* (which must only contain names
  of any *additional* slots).

* If a class defines a slot also defined in a base class, the instance
  variable defined by the base class slot is inaccessible (except by
  retrieving its descriptor directly from the base class). This
  renders the meaning of the program undefined.  In the future, a
  check may be added to prevent this.

* Nonempty *__slots__* does not work for classes derived from
  "variable-length" built-in types such as ``int``, ``str`` and
  ``tuple``.

* Any non-string iterable may be assigned to *__slots__*. Mappings may
  also be used; however, in the future, special meaning may be
  assigned to the values corresponding to each key.

* *__class__* assignment works only if both classes have the same
  *__slots__*.


Customizing class creation
--------------------------

By default, classes are constructed using ``type()``. A class
definition is read into a separate namespace and the value of class
name is bound to the result of ``type(name, bases, dict)``.

When the class definition is read, if a callable ``metaclass`` keyword
argument is passed after the bases in the class definition, the
callable given will be called instead of ``type()``.  If other keyword
arguments are passed, they will also be passed to the metaclass.  This
allows classes or functions to be written which monitor or alter the
class creation process:

* Modifying the class dictionary prior to the class being created.

* Returning an instance of another class -- essentially performing the
  role of a factory function.

These steps will have to be performed in the metaclass's ``__new__()``
method -- ``type.__new__()`` can then be called from this method to
create a class with different properties.  This example adds a new
element to the class dictionary before creating the class:

   class metacls(type):
       def __new__(mcs, name, bases, dict):
           dict['foo'] = 'metacls was here'
           return type.__new__(mcs, name, bases, dict)

You can of course also override other class methods (or add new
methods); for example defining a custom ``__call__()`` method in the
metaclass allows custom behavior when the class is called, e.g. not
always creating a new instance.

If the metaclass has a ``__prepare__()`` attribute (usually
implemented as a class or static method), it is called before the
class body is evaluated with the name of the class and a tuple of its
bases for arguments.  It should return an object that supports the
mapping interface that will be used to store the namespace of the
class.  The default is a plain dictionary.  This could be used, for
example, to keep track of the order that class attributes are declared
in by returning an ordered dictionary.

The appropriate metaclass is determined by the following precedence
rules:

* If the ``metaclass`` keyword argument is passed with the bases, it
  is used.

* Otherwise, if there is at least one base class, its metaclass is
  used.

* Otherwise, the default metaclass (``type``) is used.

The potential uses for metaclasses are boundless. Some ideas that have
been explored including logging, interface checking, automatic
delegation, automatic property creation, proxies, frameworks, and
automatic resource locking/synchronization.

Here is an example of a metaclass that uses an
``collections.OrderedDict`` to remember the order that class members
were defined:

   class OrderedClass(type):

        @classmethod
        def __prepare__(metacls, name, bases, **kwds):
           return collections.OrderedDict()

        def __new__(cls, name, bases, classdict):
           result = type.__new__(cls, name, bases, dict(classdict))
           result.members = tuple(classdict)
           return result

   class A(metaclass=OrderedClass):
       def one(self): pass
       def two(self): pass
       def three(self): pass
       def four(self): pass

   >>> A.members
   ('__module__', 'one', 'two', 'three', 'four')

When the class definition for *A* gets executed, the process begins
with calling the metaclass's ``__prepare__()`` method which returns an
empty ``collections.OrderedDict``.  That mapping records the methods
and attributes of *A* as they are defined within the body of the class
statement. Once those definitions are executed, the ordered dictionary
is fully populated and the metaclass's ``__new__()`` method gets
invoked.  That method builds the new type and it saves the ordered
dictionary keys in an attribute called ``members``.


Customizing instance and subclass checks
----------------------------------------

The following methods are used to override the default behavior of the
``isinstance()`` and ``issubclass()`` built-in functions.

In particular, the metaclass ``abc.ABCMeta`` implements these methods
in order to allow the addition of Abstract Base Classes (ABCs) as
"virtual base classes" to any class or type (including built-in
types), including other ABCs.

class.__instancecheck__(self, instance)

   Return true if *instance* should be considered a (direct or
   indirect) instance of *class*. If defined, called to implement
   ``isinstance(instance, class)``.

class.__subclasscheck__(self, subclass)

   Return true if *subclass* should be considered a (direct or
   indirect) subclass of *class*.  If defined, called to implement
   ``issubclass(subclass, class)``.

Note that these methods are looked up on the type (metaclass) of a
class.  They cannot be defined as class methods in the actual class.
This is consistent with the lookup of special methods that are called
on instances, only in this case the instance is itself a class.

See also:

   **PEP 3119** - Introducing Abstract Base Classes
      Includes the specification for customizing ``isinstance()`` and
      ``issubclass()`` behavior through ``__instancecheck__()`` and
      ``__subclasscheck__()``, with motivation for this functionality
      in the context of adding Abstract Base Classes (see the ``abc``
      module) to the language.


Emulating callable objects
--------------------------

object.__call__(self[, args...])

   Called when the instance is "called" as a function; if this method
   is defined, ``x(arg1, arg2, ...)`` is a shorthand for
   ``x.__call__(arg1, arg2, ...)``.


Emulating container types
-------------------------

The following methods can be defined to implement container objects.
Containers usually are sequences (such as lists or tuples) or mappings
(like dictionaries), but can represent other containers as well.  The
first set of methods is used either to emulate a sequence or to
emulate a mapping; the difference is that for a sequence, the
allowable keys should be the integers *k* for which ``0 <= k < N``
where *N* is the length of the sequence, or slice objects, which
define a range of items.  It is also recommended that mappings provide
the methods ``keys()``, ``values()``, ``items()``, ``get()``,
``clear()``, ``setdefault()``, ``pop()``, ``popitem()``, ``copy()``,
and ``update()`` behaving similar to those for Python's standard
dictionary objects.  The ``collections`` module provides a
``MutableMapping`` abstract base class to help create those methods
from a base set of ``__getitem__()``, ``__setitem__()``,
``__delitem__()``, and ``keys()``. Mutable sequences should provide
methods ``append()``, ``count()``, ``index()``, ``extend()``,
``insert()``, ``pop()``, ``remove()``, ``reverse()`` and ``sort()``,
like Python standard list objects.  Finally, sequence types should
implement addition (meaning concatenation) and multiplication (meaning
repetition) by defining the methods ``__add__()``, ``__radd__()``,
``__iadd__()``, ``__mul__()``, ``__rmul__()`` and ``__imul__()``
described below; they should not define other numerical operators.  It
is recommended that both mappings and sequences implement the
``__contains__()`` method to allow efficient use of the ``in``
operator; for mappings, ``in`` should search the mapping's keys; for
sequences, it should search through the values.  It is further
recommended that both mappings and sequences implement the
``__iter__()`` method to allow efficient iteration through the
container; for mappings, ``__iter__()`` should be the same as
``keys()``; for sequences, it should iterate through the values.

object.__len__(self)

   Called to implement the built-in function ``len()``.  Should return
   the length of the object, an integer ``>=`` 0.  Also, an object
   that doesn't define a ``__bool__()`` method and whose ``__len__()``
   method returns zero is considered to be false in a Boolean context.

Note: Slicing is done exclusively with the following three methods.  A
  call like

     a[1:2] = b

  is translated to

     a[slice(1, 2, None)] = b

  and so forth.  Missing slice items are always filled in with
  ``None``.

object.__getitem__(self, key)

   Called to implement evaluation of ``self[key]``. For sequence
   types, the accepted keys should be integers and slice objects.
   Note that the special interpretation of negative indexes (if the
   class wishes to emulate a sequence type) is up to the
   ``__getitem__()`` method. If *key* is of an inappropriate type,
   ``TypeError`` may be raised; if of a value outside the set of
   indexes for the sequence (after any special interpretation of
   negative values), ``IndexError`` should be raised. For mapping
   types, if *key* is missing (not in the container), ``KeyError``
   should be raised.

   Note: ``for`` loops expect that an ``IndexError`` will be raised for
     illegal indexes to allow proper detection of the end of the
     sequence.

object.__setitem__(self, key, value)

   Called to implement assignment to ``self[key]``.  Same note as for
   ``__getitem__()``.  This should only be implemented for mappings if
   the objects support changes to the values for keys, or if new keys
   can be added, or for sequences if elements can be replaced.  The
   same exceptions should be raised for improper *key* values as for
   the ``__getitem__()`` method.

object.__delitem__(self, key)

   Called to implement deletion of ``self[key]``.  Same note as for
   ``__getitem__()``.  This should only be implemented for mappings if
   the objects support removal of keys, or for sequences if elements
   can be removed from the sequence.  The same exceptions should be
   raised for improper *key* values as for the ``__getitem__()``
   method.

object.__iter__(self)

   This method is called when an iterator is required for a container.
   This method should return a new iterator object that can iterate
   over all the objects in the container.  For mappings, it should
   iterate over the keys of the container, and should also be made
   available as the method ``keys()``.

   Iterator objects also need to implement this method; they are
   required to return themselves.  For more information on iterator
   objects, see *Iterator Types*.

object.__reversed__(self)

   Called (if present) by the ``reversed()`` built-in to implement
   reverse iteration.  It should return a new iterator object that
   iterates over all the objects in the container in reverse order.

   If the ``__reversed__()`` method is not provided, the
   ``reversed()`` built-in will fall back to using the sequence
   protocol (``__len__()`` and ``__getitem__()``).  Objects that
   support the sequence protocol should only provide
   ``__reversed__()`` if they can provide an implementation that is
   more efficient than the one provided by ``reversed()``.

The membership test operators (``in`` and ``not in``) are normally
implemented as an iteration through a sequence.  However, container
objects can supply the following special method with a more efficient
implementation, which also does not require the object be a sequence.

object.__contains__(self, item)

   Called to implement membership test operators.  Should return true
   if *item* is in *self*, false otherwise.  For mapping objects, this
   should consider the keys of the mapping rather than the values or
   the key-item pairs.

   For objects that don't define ``__contains__()``, the membership
   test first tries iteration via ``__iter__()``, then the old
   sequence iteration protocol via ``__getitem__()``, see *this
   section in the language reference*.


Emulating numeric types
-----------------------

The following methods can be defined to emulate numeric objects.
Methods corresponding to operations that are not supported by the
particular kind of number implemented (e.g., bitwise operations for
non-integral numbers) should be left undefined.

object.__add__(self, other)
object.__sub__(self, other)
object.__mul__(self, other)
object.__truediv__(self, other)
object.__floordiv__(self, other)
object.__mod__(self, other)
object.__divmod__(self, other)
object.__pow__(self, other[, modulo])
object.__lshift__(self, other)
object.__rshift__(self, other)
object.__and__(self, other)
object.__xor__(self, other)
object.__or__(self, other)

   These methods are called to implement the binary arithmetic
   operations (``+``, ``-``, ``*``, ``/``, ``//``, ``%``,
   ``divmod()``, ``pow()``, ``**``, ``<<``, ``>>``, ``&``, ``^``,
   ``|``).  For instance, to evaluate the expression ``x + y``, where
   *x* is an instance of a class that has an ``__add__()`` method,
   ``x.__add__(y)`` is called.  The ``__divmod__()`` method should be
   the equivalent to using ``__floordiv__()`` and ``__mod__()``; it
   should not be related to ``__truediv__()``.  Note that
   ``__pow__()`` should be defined to accept an optional third
   argument if the ternary version of the built-in ``pow()`` function
   is to be supported.

   If one of those methods does not support the operation with the
   supplied arguments, it should return ``NotImplemented``.

object.__radd__(self, other)
object.__rsub__(self, other)
object.__rmul__(self, other)
object.__rtruediv__(self, other)
object.__rfloordiv__(self, other)
object.__rmod__(self, other)
object.__rdivmod__(self, other)
object.__rpow__(self, other)
object.__rlshift__(self, other)
object.__rrshift__(self, other)
object.__rand__(self, other)
object.__rxor__(self, other)
object.__ror__(self, other)

   These methods are called to implement the binary arithmetic
   operations (``+``, ``-``, ``*``, ``/``, ``//``, ``%``,
   ``divmod()``, ``pow()``, ``**``, ``<<``, ``>>``, ``&``, ``^``,
   ``|``) with reflected (swapped) operands. These functions are only
   called if the left operand does not support the corresponding
   operation and the operands are of different types. [2]  For
   instance, to evaluate the expression ``x - y``, where *y* is an
   instance of a class that has an ``__rsub__()`` method,
   ``y.__rsub__(x)`` is called if ``x.__sub__(y)`` returns
   *NotImplemented*.

   Note that ternary ``pow()`` will not try calling ``__rpow__()``
   (the coercion rules would become too complicated).

   Note: If the right operand's type is a subclass of the left operand's
     type and that subclass provides the reflected method for the
     operation, this method will be called before the left operand's
     non-reflected method.  This behavior allows subclasses to
     override their ancestors' operations.

object.__iadd__(self, other)
object.__isub__(self, other)
object.__imul__(self, other)
object.__itruediv__(self, other)
object.__ifloordiv__(self, other)
object.__imod__(self, other)
object.__ipow__(self, other[, modulo])
object.__ilshift__(self, other)
object.__irshift__(self, other)
object.__iand__(self, other)
object.__ixor__(self, other)
object.__ior__(self, other)

   These methods are called to implement the augmented arithmetic
   assignments (``+=``, ``-=``, ``*=``, ``/=``, ``//=``, ``%=``,
   ``**=``, ``<<=``, ``>>=``, ``&=``, ``^=``, ``|=``).  These methods
   should attempt to do the operation in-place (modifying *self*) and
   return the result (which could be, but does not have to be,
   *self*).  If a specific method is not defined, the augmented
   assignment falls back to the normal methods.  For instance, to
   execute the statement ``x += y``, where *x* is an instance of a
   class that has an ``__iadd__()`` method, ``x.__iadd__(y)`` is
   called.  If *x* is an instance of a class that does not define a
   ``__iadd__()`` method, ``x.__add__(y)`` and ``y.__radd__(x)`` are
   considered, as with the evaluation of ``x + y``.

object.__neg__(self)
object.__pos__(self)
object.__abs__(self)
object.__invert__(self)

   Called to implement the unary arithmetic operations (``-``, ``+``,
   ``abs()`` and ``~``).

object.__complex__(self)
object.__int__(self)
object.__float__(self)
object.__round__(self[, n])

   Called to implement the built-in functions ``complex()``,
   ``int()``, ``float()`` and ``round()``.  Should return a value of
   the appropriate type.

object.__index__(self)

   Called to implement ``operator.index()``.  Also called whenever
   Python needs an integer object (such as in slicing, or in the
   built-in ``bin()``, ``hex()`` and ``oct()`` functions). Must return
   an integer.


With Statement Context Managers
-------------------------------

A *context manager* is an object that defines the runtime context to
be established when executing a ``with`` statement. The context
manager handles the entry into, and the exit from, the desired runtime
context for the execution of the block of code.  Context managers are
normally invoked using the ``with`` statement (described in section
*The with statement*), but can also be used by directly invoking their
methods.

Typical uses of context managers include saving and restoring various
kinds of global state, locking and unlocking resources, closing opened
files, etc.

For more information on context managers, see *Context Manager Types*.

object.__enter__(self)

   Enter the runtime context related to this object. The ``with``
   statement will bind this method's return value to the target(s)
   specified in the ``as`` clause of the statement, if any.

object.__exit__(self, exc_type, exc_value, traceback)

   Exit the runtime context related to this object. The parameters
   describe the exception that caused the context to be exited. If the
   context was exited without an exception, all three arguments will
   be ``None``.

   If an exception is supplied, and the method wishes to suppress the
   exception (i.e., prevent it from being propagated), it should
   return a true value. Otherwise, the exception will be processed
   normally upon exit from this method.

   Note that ``__exit__()`` methods should not reraise the passed-in
   exception; this is the caller's responsibility.

See also:

   **PEP 0343** - The "with" statement
      The specification, background, and examples for the Python
      ``with`` statement.


Special method lookup
---------------------

For custom classes, implicit invocations of special methods are only
guaranteed to work correctly if defined on an object's type, not in
the object's instance dictionary.  That behaviour is the reason why
the following code raises an exception:

   >>> class C:
   ...     pass
   ...
   >>> c = C()
   >>> c.__len__ = lambda: 5
   >>> len(c)
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: object of type 'C' has no len()

The rationale behind this behaviour lies with a number of special
methods such as ``__hash__()`` and ``__repr__()`` that are implemented
by all objects, including type objects. If the implicit lookup of
these methods used the conventional lookup process, they would fail
when invoked on the type object itself:

   >>> 1 .__hash__() == hash(1)
   True
   >>> int.__hash__() == hash(int)
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: descriptor '__hash__' of 'int' object needs an argument

Incorrectly attempting to invoke an unbound method of a class in this
way is sometimes referred to as 'metaclass confusion', and is avoided
by bypassing the instance when looking up special methods:

   >>> type(1).__hash__(1) == hash(1)
   True
   >>> type(int).__hash__(int) == hash(int)
   True

In addition to bypassing any instance attributes in the interest of
correctness, implicit special method lookup generally also bypasses
the ``__getattribute__()`` method even of the object's metaclass:

   >>> class Meta(type):
   ...    def __getattribute__(*args):
   ...       print("Metaclass getattribute invoked")
   ...       return type.__getattribute__(*args)
   ...
   >>> class C(object, metaclass=Meta):
   ...     def __len__(self):
   ...         return 10
   ...     def __getattribute__(*args):
   ...         print("Class getattribute invoked")
   ...         return object.__getattribute__(*args)
   ...
   >>> c = C()
   >>> c.__len__()                 # Explicit lookup via instance
   Class getattribute invoked
   10
   >>> type(c).__len__(c)          # Explicit lookup via type
   Metaclass getattribute invoked
   10
   >>> len(c)                      # Implicit lookup
   10

Bypassing the ``__getattribute__()`` machinery in this fashion
provides significant scope for speed optimisations within the
interpreter, at the cost of some flexibility in the handling of
special methods (the special method *must* be set on the class object
itself in order to be consistently invoked by the interpreter).

-[ Footnotes ]-

[1] It *is* possible in some cases to change an object's type, under
    certain controlled conditions. It generally isn't a good idea
    though, since it can lead to some very strange behaviour if it is
    handled incorrectly.

[2] For operands of the same type, it is assumed that if the non-
    reflected method (such as ``__add__()``) fails the operation is
    not supported, which is why the reflected method is not called.
