Fixed #26483 -- Updated docs.python.org links to use Intersphinx.

docs/topics/db/queries.txt

@@ -402,9 +402,7 @@ translates (roughly) into the following SQL:
 
    Python has the ability to define functions that accept arbitrary name-value
    arguments whose names and values are evaluated at runtime. For more
-   information, see `Keyword Arguments`_ in the official Python tutorial.
-
-   .. _`Keyword Arguments`: https://docs.python.org/tutorial/controlflow.html#keyword-arguments
+   information, see :ref:`tut-keywordargs` in the official Python tutorial.
 
 The field specified in a lookup has to be the name of a model field. There's
 one exception though, in case of a :class:`~django.db.models.ForeignKey` you

docs/topics/files.txt

@@ -77,10 +77,7 @@ The ``File`` object
 ===================
 
 Internally, Django uses a :class:`django.core.files.File` instance any time it
-needs to represent a file. This object is a thin wrapper around Python's
-`built-in file object`_ with some Django-specific additions.
-
-.. _built-in file object: https://docs.python.org/library/stdtypes.html#bltin-file-objects
+needs to represent a file.
 
 Most of the time you'll simply use a ``File`` that Django's given you (i.e. a
 file attached to a model as above, or perhaps an uploaded file).

docs/topics/logging.txt

@@ -204,7 +204,8 @@ formatters to ensure that logging output is output in a useful way.
 
 Python's logging library provides several techniques to configure
 logging, ranging from a programmatic interface to configuration files.
-By default, Django uses the `dictConfig format`_.
+By default, Django uses the :ref:`dictConfig format
+<logging-config-dictschema>`.
 
 In order to configure logging, you use :setting:`LOGGING` to define a
 dictionary of logging settings. These settings describes the loggers,
@@ -231,14 +232,12 @@ Logging is configured as part of the general Django ``setup()`` function.
 Therefore, you can be certain that loggers are always ready for use in your
 project code.
 
-.. _dictConfig format: https://docs.python.org/library/logging.config.html#configuration-dictionary-schema
-
 Examples
 --------
 
-The full documentation for `dictConfig format`_ is the best source of
-information about logging configuration dictionaries. However, to give
-you a taste of what is possible, here are several examples.
+The full documentation for :ref:`dictConfig format <logging-config-dictschema>`
+is the best source of information about logging configuration dictionaries.
+However, to give you a taste of what is possible, here are several examples.
 
 First, here's a simple configuration which writes all logging from the
 :ref:`django-logger` logger to a local file::
@@ -364,7 +363,7 @@ This logging configuration does the following things:
     The ``format`` string is a normal Python formatting string
     describing the details that are to be output on each logging
     line. The full list of detail that can be output can be
-    found in the `formatter documentation`_.
+    found in :ref:`formatter-objects`.
 
   * ``verbose``, that outputs the log level name, the log
     message, plus the time, process, thread and module that
@@ -408,8 +407,6 @@ This logging configuration does the following things:
     printed to the console; ``ERROR`` and ``CRITICAL``
     messages will also be output via email.
 
-.. _formatter documentation: https://docs.python.org/library/logging.html#formatter-objects
-
 Custom logging configuration
 ----------------------------
 

docs/topics/python3.txt

@@ -16,9 +16,10 @@ Philosophy
 ==========
 
 This document assumes that you are familiar with the changes between Python 2
-and Python 3. If you aren't, read `Python's official porting guide`_ first.
-Refreshing your knowledge of unicode handling on Python 2 and 3 will help; the
-`Pragmatic Unicode`_ presentation is a good resource.
+and Python 3. If you aren't, read :ref:`Python's official porting guide
+<pyporting-howto>` first. Refreshing your knowledge of unicode handling on
+Python 2 and 3 will help; the `Pragmatic Unicode`_ presentation is a good
+resource.
 
 Django uses the *Python 2/3 Compatible Source* strategy. Of course, you're
 free to chose another strategy for your own code, especially if you don't need
@@ -42,7 +43,6 @@ developers are used to dealing with such constraints.
 Porting tools provided by Django are inspired by this philosophy, and it's
 reflected throughout this guide.
 
-.. _Python's official porting guide: https://docs.python.org/3/howto/pyporting.html
 .. _Pragmatic Unicode: http://nedbatchelder.com/text/unipain.html
 
 Porting tips

docs/topics/serialization.txt

@@ -258,7 +258,8 @@ serializer to make the format compatible with `ECMA-262`_.
 
 Be aware that not all Django output can be passed unmodified to :mod:`json`.
 For example, if you have some custom type in an object to be serialized, you'll
-have to write a `special encoder`_ for it. Something like this will work::
+have to write a custom :mod:`json` encoder for it. Something like this will
+work::
 
     from django.utils.encoding import force_text
     from django.core.serializers.json import DjangoJSONEncoder
@@ -272,7 +273,6 @@ have to write a `special encoder`_ for it. Something like this will work::
 Also note that GeoDjango provides a :doc:`customized GeoJSON serializer
 </ref/contrib/gis/serializers>`.
 
-.. _special encoder: https://docs.python.org/library/json.html#encoders-and-decoders
 .. _ecma-262: http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15
 
 YAML