Used auto-numbered lists in documentation.

docs/howto/custom-model-fields.txt

@@ -699,12 +699,12 @@ complex conversions between your Python types and your database and
 serialization formats. Here are a couple of tips to make things go more
 smoothly:
 
-1. Look at the existing Django fields (in
+#. Look at the existing Django fields (in
    :file:`django/db/models/fields/__init__.py`) for inspiration. Try to find
    a field that's similar to what you want and extend it a little bit,
    instead of creating an entirely new field from scratch.
 
-2. Put a ``__str__()`` method on the class you're wrapping up as a field. There
+#. Put a ``__str__()`` method on the class you're wrapping up as a field. There
    are a lot of places where the default behavior of the field code is to call
    ``str()`` on the value. (In our examples in this document, ``value`` would
    be a ``Hand`` instance, not a ``HandField``). So if your ``__str__()``
@@ -736,12 +736,12 @@ A few suggestions
 In addition to the above details, there are a few guidelines which can greatly
 improve the efficiency and readability of the field's code.
 
-1. The source for Django's own ``ImageField`` (in
+#. The source for Django's own ``ImageField`` (in
    ``django/db/models/fields/files.py``) is a great example of how to
    subclass ``FileField`` to support a particular type of file, as it
    incorporates all of the techniques described above.
 
-2. Cache file attributes wherever possible. Since files may be stored in
+#. Cache file attributes wherever possible. Since files may be stored in
    remote storage systems, retrieving them may cost extra time, or even
    money, that isn't always necessary. Once a file is retrieved to obtain
    some data about its content, cache as much of that data as possible to

docs/howto/custom-template-tags.txt

@@ -842,13 +842,13 @@ A naive implementation of ``CycleNode`` might look something like this::
 But, suppose we have two templates rendering the template snippet from above at
 the same time:
 
-1. Thread 1 performs its first loop iteration, ``CycleNode.render()``
+#. Thread 1 performs its first loop iteration, ``CycleNode.render()``
    returns 'row1'
-2. Thread 2 performs its first loop iteration, ``CycleNode.render()``
+#. Thread 2 performs its first loop iteration, ``CycleNode.render()``
    returns 'row2'
-3. Thread 1 performs its second loop iteration, ``CycleNode.render()``
+#. Thread 1 performs its second loop iteration, ``CycleNode.render()``
    returns 'row1'
-4. Thread 2 performs its second loop iteration, ``CycleNode.render()``
+#. Thread 2 performs its second loop iteration, ``CycleNode.render()``
    returns 'row2'
 
 The CycleNode is iterating, but it's iterating globally. As far as Thread 1

docs/howto/static-files/index.txt

@@ -11,14 +11,14 @@ This page describes how you can serve these static files.
 Configuring static files
 ========================
 
-1. Make sure that ``django.contrib.staticfiles`` is included in your
+#. Make sure that ``django.contrib.staticfiles`` is included in your
    :setting:`INSTALLED_APPS`.
 
-2. In your settings file, define :setting:`STATIC_URL`, for example::
+#. In your settings file, define :setting:`STATIC_URL`, for example::
 
       STATIC_URL = '/static/'
 
-3. In your templates, use the :ttag:`static` template tag to build the URL for
+#. In your templates, use the :ttag:`static` template tag to build the URL for
    the given relative path using the configured :setting:`STATICFILES_STORAGE`.
 
    .. _staticfiles-in-templates:
@@ -28,7 +28,7 @@ Configuring static files
         {% load static %}
         <img src="{% static "my_app/example.jpg" %}" alt="My image">
 
-4. Store your static files in a folder called ``static`` in your app. For
+#. Store your static files in a folder called ``static`` in your app. For
    example ``my_app/static/my_app/example.jpg``.
 
 .. admonition:: Serving the files
@@ -159,19 +159,19 @@ Deployment
 :mod:`django.contrib.staticfiles` provides a convenience management command
 for gathering static files in a single directory so you can serve them easily.
 
-1. Set the :setting:`STATIC_ROOT` setting to the directory from which you'd
+#. Set the :setting:`STATIC_ROOT` setting to the directory from which you'd
    like to serve these files, for example::
 
        STATIC_ROOT = "/var/www/example.com/static/"
 
-2. Run the :djadmin:`collectstatic` management command::
+#. Run the :djadmin:`collectstatic` management command::
 
        $ python manage.py collectstatic
 
    This will copy all files from your static folders into the
    :setting:`STATIC_ROOT` directory.
 
-3. Use a web server of your choice to serve the
+#. Use a web server of your choice to serve the
    files. :doc:`/howto/static-files/deployment` covers some common deployment
    strategies for static files.
 

docs/internals/organization.txt

@@ -168,12 +168,12 @@ A new board is elected after each feature release of Django. The election
 process is managed by a returns officer nominated by the outgoing technical
 board. The election process works as follows:
 
-1. Candidates advertise their application for the technical board to the team.
+#. Candidates advertise their application for the technical board to the team.
 
    They must be committers already. There's no term limit for technical board
    members.
 
-2. Each team member can vote for zero to five people among the candidates.
+#. Each team member can vote for zero to five people among the candidates.
    Candidates are ranked by the total number of votes they received.
 
    In case of a tie, the person who joined the core team earlier wins.

docs/internals/security.txt

@@ -119,18 +119,18 @@ from `Django's release team`_ and consists of:
 
 On the day of disclosure, we will take the following steps:
 
-1. Apply the relevant patch(es) to Django's codebase.
+#. Apply the relevant patch(es) to Django's codebase.
 
-2. Issue the relevant release(s), by placing new packages on `the
+#. Issue the relevant release(s), by placing new packages on `the
    Python Package Index`_ and on the Django website, and tagging the
    new release(s) in Django's git repository.
 
-3. Post a public entry on `the official Django development blog`_,
+#. Post a public entry on `the official Django development blog`_,
    describing the issue and its resolution in detail, pointing to the
    relevant patches and new releases, and crediting the reporter of
    the issue (if the reporter wishes to be publicly identified).
 
-4. Post a notice to the |django-announce| and oss-security@lists.openwall.com
+#. Post a notice to the |django-announce| and oss-security@lists.openwall.com
    mailing lists that links to the blog post.
 
 .. _the Python Package Index: https://pypi.org/

docs/intro/reusable-apps.txt

@@ -120,7 +120,7 @@ Python *packaging* refers to preparing your app in a specific format that can
 be easily installed and used. Django itself is packaged very much like
 this. For a small app like polls, this process isn't too difficult.
 
-1. First, create a parent directory for ``polls``, outside of your Django
+#. First, create a parent directory for ``polls``, outside of your Django
    project. Call this directory ``django-polls``.
 
    .. admonition::  Choosing a name for your app
@@ -137,9 +137,9 @@ this. For a small app like polls, this process isn't too difficult.
        </ref/contrib/index>`, for example ``auth``, ``admin``, or
        ``messages``.
 
-2. Move the ``polls`` directory into the ``django-polls`` directory.
+#. Move the ``polls`` directory into the ``django-polls`` directory.
 
-3. Create a file ``django-polls/README.rst`` with the following contents:
+#. Create a file ``django-polls/README.rst`` with the following contents:
 
    .. code-block:: rst
        :caption: django-polls/README.rst
@@ -174,14 +174,14 @@ this. For a small app like polls, this process isn't too difficult.
 
        5. Visit http://127.0.0.1:8000/polls/ to participate in the poll.
 
-4. Create a ``django-polls/LICENSE`` file. Choosing a license is beyond the
+#. Create a ``django-polls/LICENSE`` file. Choosing a license is beyond the
    scope of this tutorial, but suffice it to say that code released publicly
    without a license is *useless*. Django and many Django-compatible apps are
    distributed under the BSD license; however, you're free to pick your own
    license. Just be aware that your licensing choice will affect who is able
    to use your code.
 
-5. Next we'll create a ``setup.py`` file which provides details about how to
+#. Next we'll create a ``setup.py`` file which provides details about how to
    build and install the app.  A full explanation of this file is beyond the
    scope of this tutorial, but the `setuptools docs
    <https://setuptools.readthedocs.io/en/latest/>`_ have a good
@@ -226,7 +226,7 @@ this. For a small app like polls, this process isn't too difficult.
            ],
        )
 
-6. Only Python modules and packages are included in the package by default. To
+#. Only Python modules and packages are included in the package by default. To
    include additional files, we'll need to create a ``MANIFEST.in`` file. The
    setuptools docs referred to in the previous step discuss this file in more
    details. To include the templates, the ``README.rst`` and our ``LICENSE``
@@ -241,7 +241,7 @@ this. For a small app like polls, this process isn't too difficult.
        recursive-include polls/static *
        recursive-include polls/templates *
 
-7. It's optional, but recommended, to include detailed documentation with your
+#. It's optional, but recommended, to include detailed documentation with your
    app. Create an empty directory ``django-polls/docs`` for future
    documentation. Add an additional line to ``django-polls/MANIFEST.in``::
 
@@ -251,7 +251,7 @@ this. For a small app like polls, this process isn't too difficult.
    you add some files to it. Many Django apps also provide their documentation
    online through sites like `readthedocs.org <https://readthedocs.org>`_.
 
-8. Try building your package with ``python setup.py sdist`` (run from inside
+#. Try building your package with ``python setup.py sdist`` (run from inside
    ``django-polls``). This creates a directory called ``dist`` and builds your
    new package, ``django-polls-0.1.tar.gz``.
 
@@ -276,15 +276,15 @@ working. We'll now fix this by installing our new ``django-polls`` package.
    tools that run as that user, so ``virtualenv`` is a more robust solution
    (see below).
 
-1. To install the package, use pip (you already :ref:`installed it
+#. To install the package, use pip (you already :ref:`installed it
    <installing-reusable-apps-prerequisites>`, right?)::
 
     pip install --user django-polls/dist/django-polls-0.1.tar.gz
 
-2. With luck, your Django project should now work correctly again. Run the
+#. With luck, your Django project should now work correctly again. Run the
    server again to confirm this.
 
-3. To uninstall the package, use pip::
+#. To uninstall the package, use pip::
 
     pip uninstall django-polls
 

docs/intro/tutorial04.txt

@@ -211,11 +211,11 @@ Let's convert our poll app to use the generic views system, so we can delete a
 bunch of our own code. We'll just have to take a few steps to make the
 conversion. We will:
 
-1. Convert the URLconf.
+#. Convert the URLconf.
 
-2. Delete some of the old, unneeded views.
+#. Delete some of the old, unneeded views.
 
-3. Introduce new views based on Django's generic views.
+#. Introduce new views based on Django's generic views.
 
 Read on for details.
 

docs/ref/applications.txt

@@ -303,10 +303,10 @@ Django applications require a single base filesystem path where Django
 etc. Thus, namespace packages may only be Django applications if one of the
 following is true:
 
-1. The namespace package actually has only a single location (i.e. is not
+#. The namespace package actually has only a single location (i.e. is not
    spread across more than one directory.)
 
-2. The :class:`~django.apps.AppConfig` class used to configure the application
+#. The :class:`~django.apps.AppConfig` class used to configure the application
    has a :attr:`~django.apps.AppConfig.path` class attribute, which is the
    absolute directory path Django will use as the single base path for the
    application.

docs/ref/class-based-views/base.txt

@@ -24,9 +24,9 @@ MRO is an acronym for Method Resolution Order.
 
     **Method Flowchart**
 
-    1. :meth:`dispatch()`
-    2. :meth:`http_method_not_allowed()`
-    3. :meth:`options()`
+    #. :meth:`dispatch()`
+    #. :meth:`http_method_not_allowed()`
+    #. :meth:`options()`
 
     **Example views.py**::
 
@@ -123,9 +123,9 @@ MRO is an acronym for Method Resolution Order.
 
     **Method Flowchart**
 
-    1. :meth:`~django.views.generic.base.View.dispatch()`
-    2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
-    3. :meth:`~django.views.generic.base.ContextMixin.get_context_data()`
+    #. :meth:`~django.views.generic.base.View.dispatch()`
+    #. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
+    #. :meth:`~django.views.generic.base.ContextMixin.get_context_data()`
 
     **Example views.py**::
 
@@ -184,9 +184,9 @@ MRO is an acronym for Method Resolution Order.
 
     **Method Flowchart**
 
-    1. :meth:`~django.views.generic.base.View.dispatch()`
-    2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
-    3. :meth:`get_redirect_url()`
+    #. :meth:`~django.views.generic.base.View.dispatch()`
+    #. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
+    #. :meth:`get_redirect_url()`
 
     **Example views.py**::
 

docs/ref/class-based-views/generic-display.txt

@@ -25,16 +25,16 @@ many projects they are typically the most commonly used views.
 
     **Method Flowchart**
 
-    1. :meth:`~django.views.generic.base.View.dispatch()`
-    2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
-    3. :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
-    4. :meth:`~django.views.generic.detail.SingleObjectMixin.get_slug_field()`
-    5. :meth:`~django.views.generic.detail.SingleObjectMixin.get_queryset()`
-    6. :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
-    7. :meth:`~django.views.generic.detail.SingleObjectMixin.get_context_object_name()`
-    8. :meth:`~django.views.generic.detail.SingleObjectMixin.get_context_data()`
-    9. ``get()``
-    10. :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
+    #. :meth:`~django.views.generic.base.View.dispatch()`
+    #. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
+    #. :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_slug_field()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_queryset()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_context_object_name()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_context_data()`
+    #. ``get()``
+    #. :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
 
     **Example myapp/views.py**::
 
@@ -95,15 +95,14 @@ many projects they are typically the most commonly used views.
 
     **Method Flowchart**
 
-    1. :meth:`~django.views.generic.base.View.dispatch()`
-    2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
-    3. :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
-    4. :meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset()`
-    5. :meth:`~django.views.generic.list.MultipleObjectMixin.get_context_object_name()`
-    6. :meth:`~django.views.generic.list.MultipleObjectMixin.get_context_data()`
-    7. ``get()``
-    8. :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
-
+    #. :meth:`~django.views.generic.base.View.dispatch()`
+    #. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
+    #. :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
+    #. :meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset()`
+    #. :meth:`~django.views.generic.list.MultipleObjectMixin.get_context_object_name()`
+    #. :meth:`~django.views.generic.list.MultipleObjectMixin.get_context_data()`
+    #. ``get()``
+    #. :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
 
     **Example views.py**::
 

docs/ref/clickjacking.txt

@@ -40,9 +40,9 @@ loading in a frame no matter which site made the request.
 Django provides a few simple ways to include this header in responses from your
 site:
 
-1. A simple middleware that sets the header in all responses.
+#. A simple middleware that sets the header in all responses.
 
-2. A set of view decorators that can be used to override the middleware or to
+#. A set of view decorators that can be used to override the middleware or to
    only set the header for certain views.
 
 The ``X-Frame-Options`` HTTP header will only be set by the middleware or view

docs/ref/contrib/gis/install/index.txt

@@ -8,9 +8,9 @@ Overview
 ========
 In general, GeoDjango installation requires:
 
-1. :ref:`Python and Django <django>`
-2. :ref:`spatial_database`
-3. :doc:`geolibs`
+#. :ref:`Python and Django <django>`
+#. :ref:`spatial_database`
+#. :doc:`geolibs`
 
 Details for each of the requirements and installation instructions
 are provided in the sections below. In addition, platform-specific

docs/ref/contrib/gis/layermapping.txt

@@ -31,7 +31,7 @@ then inserting into a GeoDjango model.
 Example
 =======
 
-1. You need a GDAL-supported data source, like a shapefile (here we're using
+#. You need a GDAL-supported data source, like a shapefile (here we're using
    a simple polygon shapefile, ``test_poly.shp``, with three features)::
 
     >>> from django.contrib.gis.gdal import DataSource
@@ -50,7 +50,7 @@ Example
         PRIMEM["Greenwich",0],
         UNIT["Degree",0.017453292519943295]]
 
-2. Now we define our corresponding Django model (make sure to use :djadmin:`migrate`)::
+#. Now we define our corresponding Django model (make sure to use :djadmin:`migrate`)::
 
     from django.contrib.gis.db import models
 
@@ -61,7 +61,7 @@ Example
         def __str__(self):
             return 'Name: %s' % self.name
 
-3. Use :class:`LayerMapping` to extract all the features and place them in the
+#. Use :class:`LayerMapping` to extract all the features and place them in the
    database::
 
     >>> from django.contrib.gis.utils import LayerMapping