mirror of
https://github.com/django/django.git
synced 2026-02-09 02:49:25 +08:00
Fixed unbalanced parentheses in docs.
This commit is contained in:
@@ -520,7 +520,7 @@ define some extra description units:
|
||||
|
||||
Django's documentation uses a custom ``console`` directive for documenting
|
||||
command-line examples involving ``django-admin``, ``manage.py``, ``python``,
|
||||
etc.). In the HTML documentation, it renders a two-tab UI, with one tab showing
|
||||
etc. In the HTML documentation, it renders a two-tab UI, with one tab showing
|
||||
a Unix-style command prompt and a second tab showing a Windows prompt.
|
||||
|
||||
For example, you can replace this fragment:
|
||||
@@ -584,7 +584,7 @@ blank line and an optional description (indented).
|
||||
|
||||
General improvements or other changes to the APIs that should be emphasized
|
||||
should use the "``.. versionchanged:: X.Y``" directive (with the same format
|
||||
as the ``versionadded`` mentioned above.
|
||||
as the ``versionadded`` mentioned above).
|
||||
|
||||
These ``versionadded`` and ``versionchanged`` blocks should be
|
||||
"self-contained." In other words, since we only keep these annotations around
|
||||
|
||||
@@ -89,7 +89,7 @@ can be chained with other lookup functions. To use it, you need to add
|
||||
the `unaccent extension on PostgreSQL`_. The
|
||||
:class:`~django.contrib.postgres.operations.UnaccentExtension` migration
|
||||
operation is available if you want to perform this activation using
|
||||
migrations).
|
||||
migrations.
|
||||
|
||||
.. _unaccent extension on PostgreSQL: https://www.postgresql.org/docs/current/unaccent.html
|
||||
|
||||
|
||||
@@ -158,7 +158,7 @@ Alters the managers that are available during migrations.
|
||||
Adds a field to a model. ``model_name`` is the model's name, ``name`` is
|
||||
the field's name, and ``field`` is an unbound Field instance (the thing
|
||||
you would put in the field declaration in ``models.py`` - for example,
|
||||
``models.IntegerField(null=True)``.
|
||||
``models.IntegerField(null=True)``).
|
||||
|
||||
The ``preserve_default`` argument indicates whether the field's default
|
||||
value is permanent and should be baked into the project state (``True``),
|
||||
|
||||
@@ -814,7 +814,7 @@ The ``__hash__()`` method is based on the instance's primary key value. It
|
||||
is effectively ``hash(obj.pk)``. If the instance doesn't have a primary key
|
||||
value then a ``TypeError`` will be raised (otherwise the ``__hash__()``
|
||||
method would return different values before and after the instance is
|
||||
saved, but changing the :meth:`~object.__hash__` value of an instance is
|
||||
saved), but changing the :meth:`~object.__hash__` value of an instance is
|
||||
forbidden in Python.
|
||||
|
||||
``get_absolute_url()``
|
||||
|
||||
@@ -26,7 +26,7 @@ all Django builtin lookups are derived:
|
||||
|
||||
A lookup expression consists of three parts:
|
||||
|
||||
* Fields part (e.g.
|
||||
* Fields part, e.g.
|
||||
``Book.objects.filter(author__best_friends__first_name...``);
|
||||
* Transforms part (may be omitted) (e.g. ``__lower__first3chars__reversed``);
|
||||
* A lookup (e.g. ``__icontains``) that, if omitted, defaults to ``__exact``.
|
||||
|
||||
@@ -1990,7 +1990,7 @@ them:
|
||||
.. code-block:: pycon
|
||||
|
||||
>>> Person.objects.select_related("hometown").select_for_update().exclude(hometown=None)
|
||||
<QuerySet [<Person: ...)>, ...]>
|
||||
<QuerySet [<Person: ...>, ...]>
|
||||
|
||||
The ``postgresql``, ``oracle``, and ``mysql`` database backends support
|
||||
``select_for_update()``. However, MariaDB only supports the ``nowait``
|
||||
|
||||
@@ -186,7 +186,7 @@ All attributes should be considered read-only, unless stated otherwise.
|
||||
.. code-block:: pycon
|
||||
|
||||
>>> request.headers
|
||||
{'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6', ...}
|
||||
{'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6', ...)}
|
||||
|
||||
>>> "User-Agent" in request.headers
|
||||
True
|
||||
|
||||
@@ -3668,7 +3668,7 @@ usage.
|
||||
:doc:`staticfiles</ref/contrib/staticfiles>`’s
|
||||
:setting:`finders<STATICFILES_FINDERS>`, which by default, are
|
||||
``'static/'`` app sub-directories and any directories you include in
|
||||
:setting:`STATICFILES_DIRS`).
|
||||
:setting:`STATICFILES_DIRS`.
|
||||
|
||||
.. setting:: STATIC_URL
|
||||
|
||||
|
||||
@@ -620,7 +620,7 @@ Dictionary access to ``HttpRequest``
|
||||
access; previously, both ``GET`` and ``POST`` data were directly
|
||||
available on the ``HttpRequest`` object (e.g., you could check for a
|
||||
piece of form data by using ``if 'some_form_key' in request`` or by
|
||||
reading ``request['some_form_key']``. This is no longer supported; if
|
||||
reading ``request['some_form_key']``). This is no longer supported; if
|
||||
you need access to the combined ``GET`` and ``POST`` data, use
|
||||
``request.REQUEST`` instead.
|
||||
|
||||
|
||||
@@ -1204,7 +1204,7 @@ Miscellaneous
|
||||
* Private ``FileField`` methods ``get_directory_name()`` and ``get_filename()``
|
||||
are deprecated in favor of performing this work in
|
||||
:meth:`Storage.generate_filename()
|
||||
<django.core.files.storage.Storage.generate_filename>`).
|
||||
<django.core.files.storage.Storage.generate_filename>`.
|
||||
|
||||
* Old-style middleware that uses ``settings.MIDDLEWARE_CLASSES`` are
|
||||
deprecated. :ref:`Adapt old, custom middleware <upgrading-middleware>` and
|
||||
|
||||
@@ -53,7 +53,7 @@ Bugfixes
|
||||
|
||||
* Fixed queries where an expression was referenced in ``order_by()``, but
|
||||
wasn't part of the select clause. An example query is
|
||||
``qs.annotate(foo=F('field')).values('pk').order_by('foo'))``
|
||||
``qs.annotate(foo=F('field')).values('pk').order_by('foo')``
|
||||
(:ticket:`24615`).
|
||||
|
||||
* Fixed a database table name quoting regression (:ticket:`24605`).
|
||||
|
||||
@@ -1047,7 +1047,7 @@ those writing third-party backends in updating their code:
|
||||
* ``AdminSite`` no longer takes an ``app_name`` argument and its ``app_name``
|
||||
attribute has been removed. The application name is always ``admin`` (as
|
||||
opposed to the instance name which you can still customize using
|
||||
``AdminSite(name="...")``.
|
||||
``AdminSite(name="...")``).
|
||||
|
||||
* The ``ModelAdmin.get_object()`` method (private API) now takes a third
|
||||
argument named ``from_field`` in order to specify which field should match
|
||||
|
||||
@@ -653,7 +653,7 @@ disable caching for a view (using the
|
||||
.. _i18n-cache-key:
|
||||
|
||||
If :setting:`USE_I18N` is set to ``True`` then the generated cache key will
|
||||
include the name of the active :term:`language<language code>` -- see also
|
||||
include the name of the active :term:`language<language code>` (see also
|
||||
:ref:`how-django-discovers-language-preference`). This allows you to easily
|
||||
cache multilingual sites without having to create the cache key yourself.
|
||||
|
||||
|
||||
@@ -448,7 +448,7 @@ serializing these values is often straightforward
|
||||
writing a decoder that can reliably get back the same thing that you put in is
|
||||
more fragile. For example, you run the risk of returning a ``datetime`` that
|
||||
was actually a string that just happened to be in the same format chosen for
|
||||
``datetime``\s).
|
||||
``datetime``\s.
|
||||
|
||||
Your serializer class must implement two methods,
|
||||
``dumps(self, obj)`` and ``loads(self, data)``, to serialize and deserialize
|
||||
|
||||
Reference in New Issue
Block a user