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. An object's type is also
unchangeable. It determines the operations that an object supports
(e.g. ``does it have a length?'') and also defines the possible
values for objects of that type. 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 type determines an object's (im)mutability.
Objects are never explicitly destroyed; however, when they become
unreachable they may be garbage-collected. An implementation is
allowed to delay 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. (Implementation note: the current implementation uses a
reference-counting scheme which collects most objects as soon as they
become unreachable, but never collects garbage containing circular
references.)
Note that the use of the implementation's tracing or debugging facilities may keep objects alive that would normally be collectable.
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 always explicitly close such objects.
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 (im)mutability of a container, only the identities of
the immediately contained objects are implied. (So, if an immutable
container contains a reference to a mutable object, its value changes
if that mutable object is changed.)
Types affect almost all aspects of objects' lives. Even the meaning 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; c = []; d = []
a and b may or may not refer to the same object with the value one, depending on the implementation, but c and d are guaranteed to refer to two different, unique, newly created empty lists.