mirror of
https://github.com/django/django.git
synced 2024-12-22 00:55:44 +00:00
Improved style of n-tuple wording in docs and comments.
This commit is contained in:
parent
107865780a
commit
f8092ee9ad
@ -456,7 +456,7 @@ def extract_views_from_urlpatterns(urlpatterns, base="", namespace=None):
|
||||
"""
|
||||
Return a list of views from a list of urlpatterns.
|
||||
|
||||
Each object in the returned list is a four-tuple:
|
||||
Each object in the returned list is a 4-tuple:
|
||||
(view_func, regex, namespace, name)
|
||||
"""
|
||||
views = []
|
||||
|
@ -1346,7 +1346,7 @@ class BaseDatabaseSchemaEditor:
|
||||
for cases when a creation type is different to an alteration type
|
||||
(e.g. SERIAL in PostgreSQL, PostGIS fields).
|
||||
|
||||
Return a two-tuple of: an SQL fragment of (sql, params) to insert into
|
||||
Return a 2-tuple of: an SQL fragment of (sql, params) to insert into
|
||||
an ALTER TABLE statement and a list of extra (sql, params) tuples to
|
||||
run once the field is altered.
|
||||
"""
|
||||
|
@ -342,11 +342,11 @@ subclass::
|
||||
|
||||
Set ``fieldsets`` to control the layout of admin "add" and "change" pages.
|
||||
|
||||
``fieldsets`` is a list of two-tuples, in which each two-tuple represents a
|
||||
``fieldsets`` is a list of 2-tuples, in which each 2-tuple represents a
|
||||
``<fieldset>`` on the admin form page. (A ``<fieldset>`` is a "section" of
|
||||
the form.)
|
||||
|
||||
The two-tuples are in the format ``(name, field_options)``, where ``name``
|
||||
The 2-tuples are in the format ``(name, field_options)``, where ``name``
|
||||
is a string representing the title of the fieldset and ``field_options`` is
|
||||
a dictionary of information about the fieldset, including a list of fields
|
||||
to be displayed in it.
|
||||
@ -1556,7 +1556,7 @@ templates used by the :class:`ModelAdmin` views:
|
||||
|
||||
The ``get_fieldsets`` method is given the ``HttpRequest`` and the ``obj``
|
||||
being edited (or ``None`` on an add form) and is expected to return a list
|
||||
of two-tuples, in which each two-tuple represents a ``<fieldset>`` on the
|
||||
of 2-tuples, in which each 2-tuple represents a ``<fieldset>`` on the
|
||||
admin form page, as described above in the :attr:`ModelAdmin.fieldsets` section.
|
||||
|
||||
.. method:: ModelAdmin.get_list_filter(request)
|
||||
|
@ -893,7 +893,7 @@ caring about dissolving boundaries.
|
||||
*Availability*: `PostGIS <https://postgis.net/docs/ST_Extent.html>`__,
|
||||
Oracle, SpatiaLite
|
||||
|
||||
Returns the extent of all ``geo_field`` in the ``QuerySet`` as a four-tuple,
|
||||
Returns the extent of all ``geo_field`` in the ``QuerySet`` as a 4-tuple,
|
||||
comprising the lower left coordinate and the upper right coordinate.
|
||||
|
||||
Example:
|
||||
@ -915,7 +915,7 @@ Example:
|
||||
|
||||
*Availability*: `PostGIS <https://postgis.net/docs/ST_3DExtent.html>`__
|
||||
|
||||
Returns the 3D extent of all ``geo_field`` in the ``QuerySet`` as a six-tuple,
|
||||
Returns the 3D extent of all ``geo_field`` in the ``QuerySet`` as a 6-tuple,
|
||||
comprising the lower left coordinate and upper right coordinate (each with x, y,
|
||||
and z coordinates).
|
||||
|
||||
|
@ -227,7 +227,7 @@ modifications:
|
||||
concrete data type. Django supports adding an extra string value to the end
|
||||
of this tuple to be used as the human-readable name, or ``label``. The
|
||||
``label`` can be a lazy translatable string. Thus, in most cases, the member
|
||||
value will be a ``(value, label)`` two-tuple. See below for :ref:`an example
|
||||
value will be a ``(value, label)`` 2-tuple. See below for :ref:`an example
|
||||
of subclassing choices <field-choices-enum-subclassing>` using a more complex
|
||||
data type. If a tuple is not provided, or the last item is not a (lazy)
|
||||
string, the ``label`` is :ref:`automatically generated
|
||||
|
@ -765,7 +765,7 @@ first item is the first field, etc. For example:
|
||||
|
||||
If you only pass in a single field, you can also pass in the ``flat``
|
||||
parameter. If ``True``, this will mean the returned results are single values,
|
||||
rather than one-tuples. An example should make the difference clearer:
|
||||
rather than 1-tuples. An example should make the difference clearer:
|
||||
|
||||
.. code-block:: pycon
|
||||
|
||||
|
@ -1959,7 +1959,7 @@ and including a copy here would inevitably become rapidly out of date. You can
|
||||
see the current list of translated languages by looking in
|
||||
:source:`django/conf/global_settings.py`.
|
||||
|
||||
The list is a list of two-tuples in the format
|
||||
The list is a list of 2-tuples in the format
|
||||
(:term:`language code<language code>`, ``language name``) -- for example,
|
||||
``('ja', 'Japanese')``.
|
||||
This specifies which languages are available for language selection. See
|
||||
|
@ -458,7 +458,7 @@ Arguments sent with this signal:
|
||||
``plan``
|
||||
The migration plan that is going to be used for the migration run. While
|
||||
the plan is not public API, this allows for the rare cases when it is
|
||||
necessary to know the plan. A plan is a list of two-tuples with the first
|
||||
necessary to know the plan. A plan is a list of 2-tuples with the first
|
||||
item being the instance of a migration class and the second item showing
|
||||
if the migration was rolled back (``True``) or applied (``False``).
|
||||
|
||||
@ -516,7 +516,7 @@ Arguments sent with this signal:
|
||||
``plan``
|
||||
The migration plan that was used for the migration run. While the plan is
|
||||
not public API, this allows for the rare cases when it is necessary to
|
||||
know the plan. A plan is a list of two-tuples with the first item being
|
||||
know the plan. A plan is a list of 2-tuples with the first item being
|
||||
the instance of a migration class and the second item showing if the
|
||||
migration was rolled back (``True``) or applied (``False``).
|
||||
|
||||
|
@ -26,7 +26,7 @@ Bugfixes
|
||||
* Fixed a crash when using a ``__icontains`` lookup on a ``ArrayField``
|
||||
(:ticket:`28038`).
|
||||
|
||||
* Fixed a crash when using a two-tuple in ``EmailMessage``’s ``attachments``
|
||||
* Fixed a crash when using a 2-tuple in ``EmailMessage``’s ``attachments``
|
||||
argument (:ticket:`28042`).
|
||||
|
||||
* Fixed ``QuerySet.filter()`` crash when it references the name of a
|
||||
|
@ -55,7 +55,7 @@ class PaginationTests(SimpleTestCase):
|
||||
ten = nine + [10]
|
||||
eleven = ten + [11]
|
||||
tests = (
|
||||
# Each item is two tuples:
|
||||
# Each item is 2-tuple:
|
||||
# First tuple is Paginator parameters - object_list, per_page,
|
||||
# orphans, and allow_empty_first_page.
|
||||
# Second tuple is resulting Paginator attributes - count,
|
||||
@ -233,7 +233,7 @@ class PaginationTests(SimpleTestCase):
|
||||
"""
|
||||
ten = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
|
||||
tests = (
|
||||
# Each item is three tuples:
|
||||
# Each item is 3-tuple:
|
||||
# First tuple is Paginator parameters - object_list, per_page,
|
||||
# orphans, and allow_empty_first_page.
|
||||
# Second tuple is the start and end indexes of the first page.
|
||||
|
Loading…
Reference in New Issue
Block a user