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_traceback
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.exc_traceback
or 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.
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. 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.
This is typically used for debugging, so it is important that the representation is information-rich and unambiguous.
x<y
calls x.__lt__(y)
,
x<=y
calls x.__le__(y)
,
x==y
calls x.__eq__(y)
,
x!=y
and x<>y
call
x.__ne__(y)
,
x>y
calls x.__gt__(y)
, and
x>=y
calls x.__ge__(y)
.
These methods can return any value, but if the comparison operator is
used in a Boolean context, the return value should be interpretable as
a Boolean value, else a TypeError will be raised.
By convention, False
is used for false and True
for true.
There are no reflected (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. A rich
comparison method may return NotImplemented
if it does not
implement the operation for a given pair of arguments.
self < other
,
zero if self == other
, a positive integer if self >
other
. If no __cmp__(), __eq__() or
__ne__() operation is defined, class instances are compared
by object identity (``address''). See also the description of
__hash__() for some important notes on creating objects which
support custom comparison operations and are usable as dictionary
keys.
(Note: the restriction that exceptions are not propagated by
__cmp__() has been removed since Python 1.5.)
0
or
1
. When this method is not defined, __len__() is
called, if it is defined (see below). If a class defines neither
__len__() nor __nonzero__(), all its instances are
considered true.
See About this document... for information on suggesting changes.