@@ -1157,61 +1157,69 @@ Basic customization
11571157
11581158 .. index ::
11591159 single: destructor
1160+ single: finalizer
11601161 statement: del
11611162
11621163 Called when the instance is about to be destroyed. This is also called a
1163- destructor. If a base class has a :meth: `__del__ ` method, the derived class's
1164- :meth: `__del__ ` method, if any, must explicitly call it to ensure proper
1165- deletion of the base class part of the instance. Note that it is possible
1166- (though not recommended!) for the :meth: `__del__ ` method to postpone destruction
1167- of the instance by creating a new reference to it. It may then be called at a
1168- later time when this new reference is deleted. It is not guaranteed that
1169- :meth: `__del__ ` methods are called for objects that still exist when the
1170- interpreter exits.
1164+ finalizer or (improperly) a destructor. If a base class has a
1165+ :meth: `__del__ ` method, the derived class's :meth: `__del__ ` method,
1166+ if any, must explicitly call it to ensure proper deletion of the base
1167+ class part of the instance.
1168+
1169+ It is possible (though not recommended!) for the :meth: `__del__ ` method
1170+ to postpone destruction of the instance by creating a new reference to
1171+ it. This is called object *resurrection *. It is implementation-dependent
1172+ whether :meth: `__del__ ` is called a second time when a resurrected object
1173+ is about to be destroyed; the current :term: `CPython ` implementation
1174+ only calls it once.
1175+
1176+ It is not guaranteed that :meth: `__del__ ` methods are called for objects
1177+ that still exist when the interpreter exits.
11711178
11721179 .. note ::
11731180
11741181 ``del x `` doesn't directly call ``x.__del__() `` --- the former decrements
11751182 the reference count for ``x `` by one, and the latter is only called when
1176- ``x ``'s reference count reaches zero. Some common situations that may
1177- prevent the reference count of an object from going to zero include:
1178- circular references between objects (e.g., a doubly-linked list or a tree
1179- data structure with parent and child pointers); a reference to the object
1180- on the stack frame of a function that caught an exception (the traceback
1181- stored in ``sys.exc_info()[2] `` keeps the stack frame alive); or a
1182- reference to the object on the stack frame that raised an unhandled
1183- exception in interactive mode (the traceback stored in
1184- ``sys.last_traceback `` keeps the stack frame alive). The first situation
1185- can only be remedied by explicitly breaking the cycles; the second can be
1186- resolved by freeing the reference to the traceback object when it is no
1187- longer useful, and the third can be resolved by storing ``None `` in
1188- ``sys.last_traceback ``.
1189- Circular references which are garbage are detected and cleaned up when
1190- the cyclic garbage collector is enabled (it's on by default). Refer to the
1191- documentation for the :mod: `gc ` module for more information about this
1192- topic.
1183+ ``x ``'s reference count reaches zero.
1184+
1185+ .. impl-detail ::
1186+ It is possible for a reference cycle to prevent the reference count
1187+ of an object from going to zero. In this case, the cycle will be
1188+ later detected and deleted by the :term: `cyclic garbage collector
1189+ <garbage collection> `. A common cause of reference cycles is when
1190+ an exception has been caught in a local variable. The frame's
1191+ locals then reference the exception, which references its own
1192+ traceback, which references the locals of all frames caught in the
1193+ traceback.
1194+
1195+ .. seealso ::
1196+ Documentation for the :mod: `gc ` module.
11931197
11941198 .. warning ::
11951199
11961200 Due to the precarious circumstances under which :meth: `__del__ ` methods are
11971201 invoked, exceptions that occur during their execution are ignored, and a warning
1198- is printed to ``sys.stderr `` instead. Also, when :meth: `__del__ ` is invoked in
1199- response to a module being deleted (e.g., when execution of the program is
1200- done), other globals referenced by the :meth: `__del__ ` method may already have
1201- been deleted or in the process of being torn down (e.g. the import
1202- machinery shutting down). For this reason, :meth: `__del__ ` methods
1203- should do the absolute
1204- minimum needed to maintain external invariants. Starting with version 1.5,
1205- Python guarantees that globals whose name begins with a single underscore are
1206- deleted from their module before other globals are deleted; if no other
1207- references to such globals exist, this may help in assuring that imported
1208- modules are still available at the time when the :meth: `__del__ ` method is
1209- called.
1202+ is printed to ``sys.stderr `` instead. In particular:
12101203
1211- .. index ::
1212- single: repr() (built-in function); __repr__() (object method)
1204+ * :meth: `__del__ ` can be invoked when arbitrary code is being executed,
1205+ including from any arbitrary thread. If :meth: `__del__ ` needs to take
1206+ a lock or invoke any other blocking resource, it may deadlock as
1207+ the resource may already be taken by the code that gets interrupted
1208+ to execute :meth: `__del__ `.
1209+
1210+ * :meth: `__del__ ` can be executed during interpreter shutdown. As a
1211+ consequence, the global variables it needs to access (including other
1212+ modules) may already have been deleted or set to ``None ``. Python
1213+ guarantees that globals whose name begins with a single underscore
1214+ are deleted from their module before other globals are deleted; if
1215+ no other references to such globals exist, this may help in assuring
1216+ that imported modules are still available at the time when the
1217+ :meth: `__del__ ` method is called.
12131218
12141219
1220+ .. index ::
1221+ single: repr() (built-in function); __repr__() (object method)
1222+
12151223.. method :: object.__repr__(self)
12161224
12171225 Called by the :func: `repr ` built-in function to compute the "official" string
0 commit comments