From efe3ca09e029c63e25f6e19843cb0c68cc7fa816 Mon Sep 17 00:00:00 2001 From: Clifford Gama <53076065+cliff688@users.noreply.github.com> Date: Thu, 13 Mar 2025 20:18:35 +0200 Subject: Fixed incorrect formatting for inline pluralized code references in docs. --- docs/topics/db/examples/many_to_many.txt | 14 ++++++++------ docs/topics/db/optimization.txt | 4 ++-- docs/topics/db/queries.txt | 14 +++++++------- docs/topics/forms/modelforms.txt | 12 ++++++------ docs/topics/performance.txt | 9 +++++---- 5 files changed, 28 insertions(+), 25 deletions(-) (limited to 'docs/topics') diff --git a/docs/topics/db/examples/many_to_many.txt b/docs/topics/db/examples/many_to_many.txt index 2c22faaf9a..38838bb1b8 100644 --- a/docs/topics/db/examples/many_to_many.txt +++ b/docs/topics/db/examples/many_to_many.txt @@ -36,7 +36,7 @@ objects, and a ``Publication`` has multiple ``Article`` objects: What follows are examples of operations that can be performed using the Python API facilities. -Create a few ``Publications``: +Create a few ``Publication`` instances: .. code-block:: pycon @@ -74,7 +74,7 @@ Associate the ``Article`` with a ``Publication``: >>> a1.publications.add(p1) -Create another ``Article``, and set it to appear in the ``Publications``: +Create another ``Article``, and set it to appear in its publications: .. code-block:: pycon @@ -196,7 +196,8 @@ involved is a little complex): >>> Article.objects.exclude(publications=p2) ]> -If we delete a ``Publication``, its ``Articles`` won't be able to access it: +If we delete a ``Publication``, its related ``Article`` instances won't be able +to access it: .. code-block:: pycon @@ -207,7 +208,8 @@ If we delete a ``Publication``, its ``Articles`` won't be able to access it: >>> a1.publications.all() -If we delete an ``Article``, its ``Publications`` won't be able to access it: +If we delete an ``Article``, its related ``Publication`` instances won't be +able to access it: .. code-block:: pycon @@ -303,8 +305,8 @@ Recreate the ``Article`` and ``Publication`` we have deleted: >>> a2.save() >>> a2.publications.add(p1, p2, p3) -Bulk delete some ``Publications`` - references to deleted publications should -go: +Bulk delete some ``Publication`` instances, and the references to deleted +publications will no longer be included in the related entries: .. code-block:: pycon diff --git a/docs/topics/db/optimization.txt b/docs/topics/db/optimization.txt index 6b2733643f..8e54ad4ff8 100644 --- a/docs/topics/db/optimization.txt +++ b/docs/topics/db/optimization.txt @@ -427,7 +427,7 @@ objects to reduce the number of SQL queries. For example:: my_band.members.add(me) my_band.members.add(my_friend) -...where ``Bands`` and ``Artists`` have a many-to-many relationship. +...where ``Band`` and ``Artist`` are models with a many-to-many relationship. When inserting different pairs of objects into :class:`~django.db.models.ManyToManyField` or when the custom @@ -470,7 +470,7 @@ objects to reduce the number of SQL queries. For example:: my_band.members.remove(me) my_band.members.remove(my_friend) -...where ``Bands`` and ``Artists`` have a many-to-many relationship. +...where ``Band`` and ``Artist`` are models with a many-to-many relationship. When removing different pairs of objects from :class:`ManyToManyFields `, use diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt index 2c2314198f..dfd439db8c 100644 --- a/docs/topics/db/queries.txt +++ b/docs/topics/db/queries.txt @@ -178,11 +178,11 @@ model class, like so: .. note:: - ``Managers`` are accessible only via model classes, rather than from model + A ``Manager`` is accessible only via model classes, rather than from model instances, to enforce a separation between "table-level" operations and "record-level" operations. -The :class:`~django.db.models.Manager` is the main source of ``QuerySets`` for +The :class:`~django.db.models.Manager` is the main source of querysets for a model. For example, ``Blog.objects.all()`` returns a :class:`~django.db.models.query.QuerySet` that contains all ``Blog`` objects in the database. @@ -274,7 +274,7 @@ Example: >>> q2 = q1.exclude(pub_date__gte=datetime.date.today()) >>> q3 = q1.filter(pub_date__gte=datetime.date.today()) -These three ``QuerySets`` are separate. The first is a base +These three querysets are separate. The first is a base :class:`~django.db.models.query.QuerySet` containing all entries that contain a headline starting with "What". The second is a subset of the first, with an additional criteria that excludes records whose ``pub_date`` is today or in the @@ -288,7 +288,7 @@ refinement process. ``QuerySet``\s are lazy ~~~~~~~~~~~~~~~~~~~~~~~ -``QuerySets`` are lazy -- the act of creating a +``QuerySet`` objects are lazy -- the act of creating a :class:`~django.db.models.query.QuerySet` doesn't involve any database activity. You can stack filters together all day long, and Django won't actually run the query until the :class:`~django.db.models.query.QuerySet` is @@ -1725,8 +1725,8 @@ foreign-key model will have access to a :class:`~django.db.models.Manager` that returns all instances of the first model. By default, this :class:`~django.db.models.Manager` is named ``FOO_set``, where ``FOO`` is the source model name, lowercased. This :class:`~django.db.models.Manager` returns -``QuerySets``, which can be filtered and manipulated as described in the -"Retrieving objects" section above. +``QuerySet`` instances, which can be filtered and manipulated as described in +the "Retrieving objects" section above. Example: @@ -1750,7 +1750,7 @@ related_name='entries')``, the above example code would look like this: >>> b = Blog.objects.get(id=1) >>> b.entries.all() # Returns all Entry objects related to Blog. - # b.entries is a Manager that returns QuerySets. + # b.entries is a Manager that returns ``QuerySet`` instances. >>> b.entries.filter(headline__contains="Lennon") >>> b.entries.count() diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt index ef916d882d..b320d7fc04 100644 --- a/docs/topics/forms/modelforms.txt +++ b/docs/topics/forms/modelforms.txt @@ -700,10 +700,10 @@ will be localized. Form inheritance ---------------- -As with basic forms, you can extend and reuse ``ModelForms`` by inheriting -them. This is useful if you need to declare extra fields or extra methods on a -parent class for use in a number of forms derived from models. For example, -using the previous ``ArticleForm`` class: +As with basic forms, you can extend and reuse ``ModelForm`` classes by +inheriting them. This is useful if you need to declare extra fields or extra +methods on a parent class for use in a number of forms derived from models. +For example, using the previous ``ArticleForm`` class: .. code-block:: pycon @@ -983,7 +983,7 @@ value (``instances``, in the above example). When fields are missing from the form (for example because they have been excluded), these fields will not be set by the ``save()`` method. You can find more information about this restriction, which also holds for regular -``ModelForms``, in `Selecting the fields to use`_. +model forms, in `Selecting the fields to use`_. Pass ``commit=False`` to return the unsaved model instances: @@ -1104,7 +1104,7 @@ above, in :ref:`saving-objects-in-the-formset`.) Overriding ``clean()`` on a ``ModelFormSet`` -------------------------------------------- -Just like with ``ModelForms``, by default the ``clean()`` method of a +Just like with a ``ModelForm``, by default the ``clean()`` method of a ``ModelFormSet`` will validate that none of the items in the formset violate the unique constraints on your model (either ``unique``, ``unique_together`` or ``unique_for_date|month|year``). If you want to override the ``clean()`` method diff --git a/docs/topics/performance.txt b/docs/topics/performance.txt index f3342453cc..c6231a41c8 100644 --- a/docs/topics/performance.txt +++ b/docs/topics/performance.txt @@ -212,11 +212,12 @@ Laziness in Django ------------------ Django is itself quite lazy. A good example of this can be found in the -evaluation of ``QuerySets``. :ref:`QuerySets are lazy `. +evaluation of a ``QuerySet``. :ref:`QuerySets are lazy `. Thus a ``QuerySet`` can be created, passed around and combined with other -``QuerySets``, without actually incurring any trips to the database to fetch -the items it describes. What gets passed around is the ``QuerySet`` object, not -the collection of items that - eventually - will be required from the database. +``QuerySet`` instances, without actually incurring any trips to the database +to fetch the items it describes. What gets passed around is the ``QuerySet`` +object, not the collection of items that - eventually - will be required from +the database. On the other hand, :ref:`certain operations will force the evaluation of a QuerySet `. Avoiding the premature evaluation of -- cgit v1.3