Refs #36485 -- Rewrapped docs to 79 columns line length.

Lines in the docs files were manually adjusted to conform to the
79 columns limit per line (plus newline), improving readability and
consistency across the content.

docs/howto/custom-model-fields.txt

@@ -7,17 +7,18 @@ How to create custom model fields
 Introduction
 ============
 
-The :doc:`model reference </topics/db/models>` documentation explains how to use
-Django's standard field classes -- :class:`~django.db.models.CharField`,
+The :doc:`model reference </topics/db/models>` documentation explains how to
+use Django's standard field classes -- :class:`~django.db.models.CharField`,
 :class:`~django.db.models.DateField`, etc. For many purposes, those classes are
 all you'll need. Sometimes, though, the Django version won't meet your precise
 requirements, or you'll want to use a field that is entirely different from
 those shipped with Django.
 
-Django's built-in field types don't cover every possible database column type --
-only the common types, such as ``VARCHAR`` and ``INTEGER``. For more obscure
+Django's built-in field types don't cover every possible database column type
+-- only the common types, such as ``VARCHAR`` and ``INTEGER``. For more obscure
 column types, such as geographic polygons or even user-created types such as
-`PostgreSQL custom types`_, you can define your own Django ``Field`` subclasses.
+`PostgreSQL custom types`_, you can define your own Django ``Field``
+subclasses.
 
 .. _PostgreSQL custom types: https://www.postgresql.org/docs/current/sql-createtype.html
 
@@ -106,13 +107,13 @@ What does a field class do?
 ---------------------------
 
 All of Django's fields (and when we say *fields* in this document, we always
-mean model fields and not :doc:`form fields </ref/forms/fields>`) are subclasses
-of :class:`django.db.models.Field`. Most of the information that Django records
-about a field is common to all fields -- name, help text, uniqueness and so
-forth. Storing all that information is handled by ``Field``. We'll get into the
-precise details of what ``Field`` can do later on; for now, suffice it to say
-that everything descends from ``Field`` and then customizes key pieces of the
-class behavior.
+mean model fields and not :doc:`form fields </ref/forms/fields>`) are
+subclasses of :class:`django.db.models.Field`. Most of the information that
+Django records about a field is common to all fields -- name, help text,
+uniqueness and so forth. Storing all that information is handled by ``Field``.
+We'll get into the precise details of what ``Field`` can do later on; for now,
+suffice it to say that everything descends from ``Field`` and then customizes
+key pieces of the class behavior.
 
 It's important to realize that a Django field class is not what is stored in
 your model attributes. The model attributes contain normal Python objects. The
@@ -149,9 +150,9 @@ is most similar to. Can you subclass an existing Django field and save yourself
 some work? If not, you should subclass the :class:`~django.db.models.Field`
 class, from which everything is descended.
 
-Initializing your new field is a matter of separating out any arguments that are
-specific to your case from the common arguments and passing the latter to the
-``__init__()`` method of :class:`~django.db.models.Field` (or your parent
+Initializing your new field is a matter of separating out any arguments that
+are specific to your case from the common arguments and passing the latter to
+the ``__init__()`` method of :class:`~django.db.models.Field` (or your parent
 class).
 
 In our example, we'll call our field ``HandField``. (It's a good idea to call
@@ -214,9 +215,9 @@ The ``Field.__init__()`` method takes the following parameters:
 * :attr:`~django.db.models.Field.choices`
 * :attr:`~django.db.models.Field.help_text`
 * :attr:`~django.db.models.Field.db_column`
-* :attr:`~django.db.models.Field.db_tablespace`: Only for index creation, if the
-  backend supports :doc:`tablespaces </topics/db/tablespaces>`. You can usually
-  ignore this option.
+* :attr:`~django.db.models.Field.db_tablespace`: Only for index creation, if
+  the backend supports :doc:`tablespaces </topics/db/tablespaces>`. You can
+  usually ignore this option.
 * :attr:`~django.db.models.Field.auto_created`: ``True`` if the field was
   automatically created, as for the :class:`~django.db.models.OneToOneField`
   used by model inheritance. For advanced use only.
@@ -253,9 +254,9 @@ name and import path. You do, however, have to care about the positional
 and keyword arguments, as these are likely the things you are changing.
 
 For example, in our ``HandField`` class we're always forcibly setting
-max_length in ``__init__()``. The ``deconstruct()`` method on the base ``Field``
-class will see this and try to return it in the keyword arguments; thus,
-we can drop it from the keyword arguments for readability::
+max_length in ``__init__()``. The ``deconstruct()`` method on the base
+``Field`` class will see this and try to return it in the keyword arguments;
+thus, we can drop it from the keyword arguments for readability::
 
     from django.db import models
 
@@ -471,10 +472,11 @@ over this field. You are then responsible for creating the column in the right
 table in some other way, but this gives you a way to tell Django to get out of
 the way.
 
-The :meth:`~Field.rel_db_type` method is called by fields such as ``ForeignKey``
-and ``OneToOneField`` that point to another field to determine their database
-column data types. For example, if you have an ``UnsignedAutoField``, you also
-need the foreign keys that point to that field to use the same data type::
+The :meth:`~Field.rel_db_type` method is called by fields such as
+``ForeignKey`` and ``OneToOneField`` that point to another field to determine
+their database column data types. For example, if you have an
+``UnsignedAutoField``, you also need the foreign keys that point to that field
+to use the same data type::
 
     # MySQL unsigned integer (range 0 to 4294967295).
     class UnsignedAutoField(models.AutoField):
@@ -648,8 +650,8 @@ a custom form field (and even a form widget). See the :doc:`forms documentation
 If you wish to exclude the field from the :class:`~django.forms.ModelForm`, you
 can override the :meth:`~Field.formfield` method to return ``None``.
 
-Continuing our ongoing example, we can write the :meth:`~Field.formfield` method
-as::
+Continuing our ongoing example, we can write the :meth:`~Field.formfield`
+method as::
 
     class HandField(models.Field):
         # ...