[3.11] gh-101100: Fix Sphinx warnings in Doc/library/weakref.rst (GH-109881) (#109883)

Co-authored-by: Nikita Sobolev <[email protected]>

Author: miss-islington

Doc/library/weakref.rst

@@ -111,7 +111,7 @@ See :ref:`__slots__ documentation <slots>` for details.
 
    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
-   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
    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`.
 
 :class:`WeakValueDictionary` objects have an additional method that has the
-same issues as the :meth:`keyrefs` method of :class:`WeakKeyDictionary`
-objects.
+same issues as the :meth:`WeakKeyDictionary.keyrefs` method.
 
 
 .. method:: WeakValueDictionary.valuerefs()
@@ -281,7 +280,7 @@ objects.
    Exceptions raised by finalizer callbacks during garbage collection
    will be shown on the standard error output, but cannot be
    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.
 
    When the program exits, each remaining live finalizer is called
@@ -523,18 +522,18 @@ is still alive.  For instance
    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
 directories.  The directories should be deleted with their contents
 when the first of the following events occurs:
 
 * 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.
 
-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::
 
     class TempDir:
@@ -553,12 +552,12 @@ follows::
         def __del__(self):
             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
 no longer forced to :const:`None` during :term:`interpreter shutdown`.
 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
 collector implementation.
 

Doc/tools/.nitignore

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