gh-101100: Fix Sphinx warnings in Doc/library/weakref.rst (#109881)

This commit is contained in:
Nikita Sobolev 2023-09-26 10:46:09 +03:00 committed by GitHub
parent 0b4e090422
commit 7c61a361fc
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 9 additions and 11 deletions

View file

@ -111,7 +111,7 @@ See :ref:`__slots__ documentation <slots>` for details.
Exceptions raised by the callback will be noted on the standard error output, Exceptions raised by the callback will be noted on the standard error output,
but cannot be propagated; they are handled in exactly the same way as exceptions but cannot be propagated; they are handled in exactly the same way as exceptions
raised from an object's :meth:`__del__` method. raised from an object's :meth:`~object.__del__` method.
Weak references are :term:`hashable` if the *object* is hashable. They will Weak references are :term:`hashable` if the *object* is hashable. They will
maintain their hash value even after the *object* was deleted. If maintain their hash value even after the *object* was deleted. If
@ -221,8 +221,7 @@ than needed.
Added support for ``|`` and ``|=`` operators, as specified in :pep:`584`. Added support for ``|`` and ``|=`` operators, as specified in :pep:`584`.
:class:`WeakValueDictionary` objects have an additional method that has the :class:`WeakValueDictionary` objects have an additional method that has the
same issues as the :meth:`keyrefs` method of :class:`WeakKeyDictionary` same issues as the :meth:`WeakKeyDictionary.keyrefs` method.
objects.
.. method:: WeakValueDictionary.valuerefs() .. method:: WeakValueDictionary.valuerefs()
@ -281,7 +280,7 @@ objects.
Exceptions raised by finalizer callbacks during garbage collection Exceptions raised by finalizer callbacks during garbage collection
will be shown on the standard error output, but cannot be will be shown on the standard error output, but cannot be
propagated. They are handled in the same way as exceptions raised propagated. They are handled in the same way as exceptions raised
from an object's :meth:`__del__` method or a weak reference's from an object's :meth:`~object.__del__` method or a weak reference's
callback. callback.
When the program exits, each remaining live finalizer is called When the program exits, each remaining live finalizer is called
@ -523,18 +522,18 @@ is still alive. For instance
obj dead or exiting obj dead or exiting
Comparing finalizers with :meth:`__del__` methods Comparing finalizers with :meth:`~object.__del__` methods
------------------------------------------------- ---------------------------------------------------------
Suppose we want to create a class whose instances represent temporary Suppose we want to create a class whose instances represent temporary
directories. The directories should be deleted with their contents directories. The directories should be deleted with their contents
when the first of the following events occurs: when the first of the following events occurs:
* the object is garbage collected, * the object is garbage collected,
* the object's :meth:`remove` method is called, or * the object's :meth:`!remove` method is called, or
* the program exits. * the program exits.
We might try to implement the class using a :meth:`__del__` method as We might try to implement the class using a :meth:`~object.__del__` method as
follows:: follows::
class TempDir: class TempDir:
@ -553,12 +552,12 @@ follows::
def __del__(self): def __del__(self):
self.remove() self.remove()
Starting with Python 3.4, :meth:`__del__` methods no longer prevent Starting with Python 3.4, :meth:`~object.__del__` methods no longer prevent
reference cycles from being garbage collected, and module globals are reference cycles from being garbage collected, and module globals are
no longer forced to :const:`None` during :term:`interpreter shutdown`. no longer forced to :const:`None` during :term:`interpreter shutdown`.
So this code should work without any issues on CPython. So this code should work without any issues on CPython.
However, handling of :meth:`__del__` methods is notoriously implementation However, handling of :meth:`~object.__del__` methods is notoriously implementation
specific, since it depends on internal details of the interpreter's garbage specific, since it depends on internal details of the interpreter's garbage
collector implementation. collector implementation.

View file

@ -133,7 +133,6 @@ Doc/library/unittest.mock.rst
Doc/library/unittest.rst Doc/library/unittest.rst
Doc/library/urllib.parse.rst Doc/library/urllib.parse.rst
Doc/library/urllib.request.rst Doc/library/urllib.request.rst
Doc/library/weakref.rst
Doc/library/wsgiref.rst Doc/library/wsgiref.rst
Doc/library/xml.dom.minidom.rst Doc/library/xml.dom.minidom.rst
Doc/library/xml.dom.pulldom.rst Doc/library/xml.dom.pulldom.rst