mirror of
https://github.com/django/django.git
synced 2025-10-23 21:59:11 +00:00
Converted links to external topics so they use intersphinx extension markup.
This allows to make these links more resilent to changes in the target URLs. Thanks Jannis for the report and Aymeric Augustin for the patch. Fixes #16586. git-svn-id: http://code.djangoproject.com/svn/django/trunk@16720 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
@@ -500,9 +500,9 @@ Has one **required** argument:
|
||||
setting to determine the value of the :attr:`~django.core.files.File.url`
|
||||
attribute.
|
||||
|
||||
This path may contain `strftime formatting`_, which will be replaced by the
|
||||
date/time of the file upload (so that uploaded files don't fill up the given
|
||||
directory).
|
||||
This path may contain :func:`~time.strftime` formatting, which will be
|
||||
replaced by the date/time of the file upload (so that uploaded files don't
|
||||
fill up the given directory).
|
||||
|
||||
This may also be a callable, such as a function, which will be called to
|
||||
obtain the upload path, including the filename. This callable must be able
|
||||
@@ -560,10 +560,10 @@ takes a few steps:
|
||||
|
||||
For example, say your :setting:`MEDIA_ROOT` is set to ``'/home/media'``, and
|
||||
:attr:`~FileField.upload_to` is set to ``'photos/%Y/%m/%d'``. The ``'%Y/%m/%d'``
|
||||
part of :attr:`~FileField.upload_to` is `strftime formatting`_; ``'%Y'`` is the
|
||||
four-digit year, ``'%m'`` is the two-digit month and ``'%d'`` is the two-digit
|
||||
day. If you upload a file on Jan. 15, 2007, it will be saved in the directory
|
||||
``/home/media/photos/2007/01/15``.
|
||||
part of :attr:`~FileField.upload_to` is :func:`~time.strftime` formatting;
|
||||
``'%Y'`` is the four-digit year, ``'%m'`` is the two-digit month and ``'%d'`` is
|
||||
the two-digit day. If you upload a file on Jan. 15, 2007, it will be saved in
|
||||
the directory ``/home/media/photos/2007/01/15``.
|
||||
|
||||
If you wanted to retrieve the uploaded file's on-disk filename, or the file's
|
||||
size, you could use the :attr:`~django.core.files.File.name` and
|
||||
@@ -595,8 +595,6 @@ By default, :class:`FileField` instances are
|
||||
created as ``varchar(100)`` columns in your database. As with other fields, you
|
||||
can change the maximum length using the :attr:`~CharField.max_length` argument.
|
||||
|
||||
.. _`strftime formatting`: http://docs.python.org/library/time.html#time.strftime
|
||||
|
||||
FileField and FieldFile
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -711,11 +709,8 @@ The admin represents this as an ``<input type="text">`` (a single-line input).
|
||||
:class:`DecimalField` class. Although they both represent real numbers, they
|
||||
represent those numbers differently. ``FloatField`` uses Python's ``float``
|
||||
type internally, while ``DecimalField`` uses Python's ``Decimal`` type. For
|
||||
information on the difference between the two, see Python's documentation on
|
||||
`Decimal fixed point and floating point arithmetic`_.
|
||||
|
||||
.. _Decimal fixed point and floating point arithmetic: http://docs.python.org/library/decimal.html
|
||||
|
||||
information on the difference between the two, see Python's documentation
|
||||
for the :mod:`decimal` module.
|
||||
|
||||
``ImageField``
|
||||
--------------
|
||||
@@ -777,13 +772,11 @@ An IPv4 or IPv6 address, in string format (e.g. ``192.0.2.30`` or
|
||||
``2a02:42fe::4``). The admin represents this as an ``<input type="text">``
|
||||
(a single-line input).
|
||||
|
||||
The IPv6 address normalization follows `RFC4291 section 2.2`_, including using
|
||||
the IPv4 format suggested in paragraph 3 of that section, like
|
||||
The IPv6 address normalization follows :rfc:`4291#section-2.2` section 2.2,
|
||||
including using the IPv4 format suggested in paragraph 3 of that section, like
|
||||
``::ffff:192.0.2.0``. For example, ``2001:0::0:01`` would be normalized to
|
||||
``2001::1``, and ``::ffff:0a0a:0a0a`` to ``::ffff:10.10.10.10``. All
|
||||
characters are converted to lowercase.
|
||||
|
||||
.. _RFC4291 section 2.2: http://tools.ietf.org/html/rfc4291#section-2.2
|
||||
``2001::1``, and ``::ffff:0a0a:0a0a`` to ``::ffff:10.10.10.10``. All characters
|
||||
are converted to lowercase.
|
||||
|
||||
.. attribute:: GenericIPAddressField.protocol
|
||||
|
||||
|
||||
@@ -454,7 +454,7 @@ in ``get_absolute_url()`` and have all your other code call that one place.
|
||||
|
||||
.. note::
|
||||
The string you return from ``get_absolute_url()`` **must** contain only
|
||||
ASCII characters (required by the URI specfication, `RFC 2396`_) and be
|
||||
ASCII characters (required by the URI specfication, :rfc:`2396`) and be
|
||||
URL-encoded, if necessary.
|
||||
|
||||
Code and templates calling ``get_absolute_url()`` should be able to use the
|
||||
@@ -463,8 +463,6 @@ in ``get_absolute_url()`` and have all your other code call that one place.
|
||||
are using unicode strings containing characters outside the ASCII range at
|
||||
all.
|
||||
|
||||
.. _RFC 2396: http://www.ietf.org/rfc/rfc2396.txt
|
||||
|
||||
The ``permalink`` decorator
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@@ -81,7 +81,7 @@ You can evaluate a ``QuerySet`` in the following ways:
|
||||
Pickling QuerySets
|
||||
------------------
|
||||
|
||||
If you pickle_ a ``QuerySet``, this will force all the results to be loaded
|
||||
If you :mod:`pickle` a ``QuerySet``, this will force all the results to be loaded
|
||||
into memory prior to pickling. Pickling is usually used as a precursor to
|
||||
caching and when the cached queryset is reloaded, you want the results to
|
||||
already be present and ready for use (reading from the database can take some
|
||||
@@ -112,8 +112,6 @@ described here.
|
||||
Django version N+1. Pickles should not be used as part of a long-term
|
||||
archival strategy.
|
||||
|
||||
.. _pickle: http://docs.python.org/library/pickle.html
|
||||
|
||||
.. _queryset-api:
|
||||
|
||||
QuerySet API
|
||||
@@ -1210,20 +1208,18 @@ iterator
|
||||
|
||||
.. method:: iterator()
|
||||
|
||||
Evaluates the ``QuerySet`` (by performing the query) and returns an `iterator`_
|
||||
over the results. A ``QuerySet`` typically caches its results internally so
|
||||
that repeated evaluations do not result in additional queries. In contrast,
|
||||
``iterator()`` will read results directly, without doing any caching at the
|
||||
``QuerySet`` level (internally, the default iterator calls ``iterator()`` and
|
||||
caches the return value). For a ``QuerySet`` which returns a large number of
|
||||
Evaluates the ``QuerySet`` (by performing the query) and returns an iterator
|
||||
(see :pep:`234`) over the results. A ``QuerySet`` typically caches its results
|
||||
internally so that repeated evaluations do not result in additional queries. In
|
||||
contrast, ``iterator()`` will read results directly, without doing any caching
|
||||
at the ``QuerySet`` level (internally, the default iterator calls ``iterator()``
|
||||
and caches the return value). For a ``QuerySet`` which returns a large number of
|
||||
objects that you only need to access once, this can results in better
|
||||
performance and a significant reduction in memory.
|
||||
|
||||
Note that using ``iterator()`` on a ``QuerySet`` which has already been
|
||||
evaluated will force it to evaluate again, repeating the query.
|
||||
|
||||
.. _iterator: http://www.python.org/dev/peps/pep-0234/
|
||||
|
||||
latest
|
||||
~~~~~~
|
||||
|
||||
|
||||
Reference in New Issue
Block a user