Fixed #36570 -- Removed unnecessary :py domain from documentation roles.

Signed-off-by: SaJH <wogur981208@gmail.com>

docs/topics/async.txt

@@ -312,7 +312,7 @@ Threadlocals and contextvars values are preserved across the boundary in both
 directions.
 
 :func:`async_to_sync` is essentially a more powerful version of the
-:py:func:`asyncio.run` function in Python's standard library. As well
+:func:`asyncio.run` function in Python's standard library. As well
 as ensuring threadlocals work, it also enables the ``thread_sensitive`` mode of
 :func:`sync_to_async` when that wrapper is used below it.
 

docs/topics/db/queries.txt

@@ -1060,7 +1060,7 @@ representation of the JSON scalar ``null`` is the same as SQL ``NULL``, i.e.
 ``None``. Therefore, it can be hard to distinguish between them.
 
 This only applies to ``None`` as the top-level value of the field. If ``None``
-is inside a :py:class:`list` or :py:class:`dict`, it will always be interpreted
+is inside a :class:`list` or :class:`dict`, it will always be interpreted
 as JSON ``null``.
 
 When querying, ``None`` value will always be interpreted as JSON ``null``. To

docs/topics/db/transactions.txt

@@ -113,7 +113,7 @@ Django provides a single API to control database transactions.
     durability and can be achieved by setting ``durable=True``. If the
     ``atomic`` block is nested within another it raises a ``RuntimeError``.
 
-    ``atomic`` is usable both as a :py:term:`decorator`::
+    ``atomic`` is usable both as a :term:`decorator`::
 
         from django.db import transaction
 
@@ -123,7 +123,7 @@ Django provides a single API to control database transactions.
             # This code executes inside a transaction.
             do_stuff()
 
-    and as a :py:term:`context manager`::
+    and as a :term:`context manager`::
 
         from django.db import transaction
 

docs/topics/email.txt

@@ -418,11 +418,11 @@ The class has the following methods:
 
   The keyword argument ``policy`` allows specifying the set of rules for
   updating and serializing the representation of the message. It must be an
-  :py:mod:`email.policy.Policy <email.policy>` object. Defaults to
-  :py:data:`email.policy.default`. In certain cases you may want to use
-  :py:data:`~email.policy.SMTP`, :py:data:`~email.policy.SMTPUTF8` or a custom
+  :mod:`email.policy.Policy <email.policy>` object. Defaults to
+  :data:`email.policy.default`. In certain cases you may want to use
+  :data:`~email.policy.SMTP`, :data:`~email.policy.SMTPUTF8` or a custom
   policy. For example, :class:`django.core.mail.backends.smtp.EmailBackend`
-  uses the :py:data:`~email.policy.SMTP` policy to ensure ``\r\n`` line endings
+  uses the :data:`~email.policy.SMTP` policy to ensure ``\r\n`` line endings
   as required by the SMTP protocol.
 
   If you ever need to extend Django's :class:`~django.core.mail.EmailMessage`
@@ -432,7 +432,7 @@ The class has the following methods:
   .. versionchanged:: 6.0
 
       The ``policy`` keyword argument was added and the return type was updated
-      to an instance of :py:class:`~email.message.EmailMessage`.
+      to an instance of :class:`~email.message.EmailMessage`.
 
 * ``recipients()`` returns a list of all the recipients of the message,
   whether they're recorded in the ``to``, ``cc`` or ``bcc`` attributes. This

docs/topics/forms/formsets.txt

@@ -50,8 +50,8 @@ following example will create a formset class to display two blank forms:
 
 Formsets can be iterated and indexed, accessing forms in the order they were
 created. You can reorder the forms by overriding the default
-:py:meth:`iteration <object.__iter__>` and
-:py:meth:`indexing <object.__getitem__>` behavior if needed.
+:meth:`iteration <object.__iter__>` and
+:meth:`indexing <object.__getitem__>` behavior if needed.
 
 .. _formsets-initial-data:
 

docs/topics/i18n/translation.txt

@@ -129,7 +129,7 @@ have more than a single parameter. If you used positional interpolation,
 translations wouldn't be able to reorder placeholder text.
 
 Since string extraction is done by the ``xgettext`` command, only syntaxes
-supported by ``gettext`` are supported by Django. Python :py:ref:`f-strings
+supported by ``gettext`` are supported by Django. Python :ref:`f-strings
 <f-strings>` cannot be used directly with ``gettext`` functions because
 f-string expressions are evaluated before they reach ``gettext``. This means
 ``_(f"Welcome {name}")`` will not work as expected, as the variable is

docs/topics/performance.txt

@@ -204,7 +204,7 @@ therefore have performance implications, and the more expensive the work
 concerned, the more there is to gain through laziness.
 
 Python provides a number of tools for lazy evaluation, particularly through the
-:py:term:`generator` and :py:term:`generator expression` constructs. It's worth
+:term:`generator` and :term:`generator expression` constructs. It's worth
 reading up on laziness in Python to discover opportunities for making use of
 lazy patterns in your code.
 

docs/topics/settings.txt

@@ -44,7 +44,7 @@ by using an environment variable, :envvar:`DJANGO_SETTINGS_MODULE`.
 
 The value of :envvar:`DJANGO_SETTINGS_MODULE` should be in Python path syntax,
 e.g. ``mysite.settings``. Note that the settings module should be on the
-Python :py:data:`sys.path`.
+Python :data:`sys.path`.
 
 
 The ``django-admin`` utility

docs/topics/signing.txt

@@ -116,7 +116,7 @@ generate signatures. You can use a different secret by passing it to the
     separate values. ``sep`` cannot be in the :rfc:`URL safe base64 alphabet
     <4648#section-5>`. This alphabet contains alphanumeric characters, hyphens,
     and underscores. ``algorithm`` must be an algorithm supported by
-    :py:mod:`hashlib`, it defaults to ``'sha256'``. ``fallback_keys`` is a list
+    :mod:`hashlib`, it defaults to ``'sha256'``. ``fallback_keys`` is a list
     of additional values used to validate signed data, defaults to
     :setting:`SECRET_KEY_FALLBACKS`.
 
@@ -192,7 +192,7 @@ created within a specified period of time:
 
         Checks if ``value`` was signed less than ``max_age`` seconds ago,
         otherwise raises ``SignatureExpired``. The ``max_age`` parameter can
-        accept an integer or a :py:class:`datetime.timedelta` object.
+        accept an integer or a :class:`datetime.timedelta` object.
 
     .. method:: sign_object(obj, serializer=JSONSerializer, compress=False)
 
@@ -203,7 +203,7 @@ created within a specified period of time:
 
         Checks if ``signed_obj`` was signed less than ``max_age`` seconds ago,
         otherwise raises ``SignatureExpired``. The ``max_age`` parameter can
-        accept an integer or a :py:class:`datetime.timedelta` object.
+        accept an integer or a :class:`datetime.timedelta` object.
 
 .. _signing-complex-data:
 

docs/topics/templates.txt

@@ -660,7 +660,7 @@ adds defaults that differ from Jinja2's for a few options:
     is more in line with the design of Jinja2.
 
 The default configuration is purposefully kept to a minimum. If a template is
-rendered with a request (e.g. when using :py:func:`~django.shortcuts.render`),
+rendered with a request (e.g. when using :func:`~django.shortcuts.render`),
 the ``Jinja2`` backend adds the globals ``request``, ``csrf_input``, and
 ``csrf_token`` to the context. Apart from that, this backend doesn't create a
 Django-flavored environment. It doesn't know about Django filters and tags.

docs/topics/testing/advanced.txt

@@ -587,7 +587,7 @@ and tear down the test suite.
 
     If ``buffer`` is ``True``, outputs from passing tests will be discarded.
 
-    If ``enable_faulthandler`` is ``True``, :py:mod:`faulthandler` will be
+    If ``enable_faulthandler`` is ``True``, :mod:`faulthandler` will be
     enabled.
 
     If ``timing`` is ``True``, test timings, including database setup and total
@@ -601,7 +601,7 @@ and tear down the test suite.
     :ref:`Grouping by test class <order-of-tests>` is preserved when using this
     option.
 
-    ``logger`` can be used to pass a Python :py:ref:`Logger object <logger>`.
+    ``logger`` can be used to pass a Python :ref:`Logger object <logger>`.
     If provided, the logger will be used to log messages instead of printing to
     the console. The logger object will respect its logging level rather than
     the ``verbosity``.
@@ -661,7 +661,7 @@ Methods
 
     Override this class method to add custom arguments accepted by the
     :djadmin:`test` management command. See
-    :py:meth:`argparse.ArgumentParser.add_argument` for details about adding
+    :meth:`argparse.ArgumentParser.add_argument` for details about adding
     arguments to a parser.
 
 .. method:: DiscoverRunner.setup_test_environment(**kwargs)

docs/topics/testing/overview.txt

@@ -83,7 +83,7 @@ your project's ``manage.py`` utility:
 
     $ ./manage.py test
 
-Test discovery is based on the unittest module's :py:ref:`built-in test
+Test discovery is based on the unittest module's :ref:`built-in test
 discovery <unittest-test-discovery>`. By default, this will discover tests in
 any file named ``test*.py`` under the current working directory.
 

docs/topics/testing/tools.txt

@@ -965,7 +965,7 @@ It also provides an additional method:
     called before each test, negating the speed benefits.
 
     Objects assigned to class attributes in ``setUpTestData()`` must support
-    creating deep copies with :py:func:`copy.deepcopy` in order to isolate them
+    creating deep copies with :func:`copy.deepcopy` in order to isolate them
     from alterations performed by each test methods.
 
 .. classmethod:: TestCase.captureOnCommitCallbacks(using=DEFAULT_DB_ALIAS, execute=False)