Fixed #18934 - Removed versionadded/changed annotations for Django 1.3
This commit is contained in:
Tim Graham
parent
e06b54391d
commit
837425b425
|
|
@ -760,8 +760,6 @@ A few things to note about the ``simple_tag`` helper function:
|
|||
* If the argument was a template variable, our function is passed the
|
||||
current value of the variable, not the variable itself.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
If your template tag needs to access the current context, you can use the
|
||||
``takes_context`` argument when registering your tag:
|
||||
|
||||
|
|
|
|||
|
|
@ -44,8 +44,6 @@ setting.
|
|||
|
||||
.. seealso::
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Server error emails are sent using the logging framework, so you can
|
||||
customize this behavior by :doc:`customizing your logging configuration
|
||||
</topics/logging>`.
|
||||
|
|
@ -99,8 +97,6 @@ The best way to disable this behavior is to set
|
|||
|
||||
.. seealso::
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
404 errors are logged using the logging framework. By default, these log
|
||||
records are ignored, but you can use them for error reporting by writing a
|
||||
handler and :doc:`configuring logging </topics/logging>` appropriately.
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
Managing static files
|
||||
=====================
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Django developers mostly concern themselves with the dynamic parts of web
|
||||
applications -- the views and templates that render anew for each request. But
|
||||
web applications have other parts: the static files (images, CSS,
|
||||
|
|
|
|||
|
|
@ -155,8 +155,6 @@ Certain APIs are explicitly marked as "internal" in a couple of ways:
|
|||
Local flavors
|
||||
-------------
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
:mod:`django.contrib.localflavor` contains assorted pieces of code
|
||||
that are useful for particular countries or cultures. This data is
|
||||
local in nature, and is subject to change on timelines that will
|
||||
|
|
|
|||
|
|
@ -129,8 +129,6 @@ subclass::
|
|||
|
||||
date_hierarchy = 'pub_date'
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
This will intelligently populate itself based on available data,
|
||||
e.g. if all the dates are in one month, it'll show the day-level
|
||||
drill-down only.
|
||||
|
|
@ -576,8 +574,6 @@ subclass::
|
|||
class PersonAdmin(ModelAdmin):
|
||||
list_filter = ('is_staff', 'company')
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Field names in ``list_filter`` can also span relations
|
||||
using the ``__`` lookup, for example::
|
||||
|
||||
|
|
@ -748,8 +744,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.paginator
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The paginator class to be used for pagination. By default,
|
||||
:class:`django.core.paginator.Paginator` is used. If the custom paginator
|
||||
class doesn't have the same constructor interface as
|
||||
|
|
@ -966,8 +960,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.delete_model(self, request, obj)
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The ``delete_model`` method is given the ``HttpRequest`` and a model
|
||||
instance. Use this method to do pre- or post-delete operations.
|
||||
|
||||
|
|
@ -1213,8 +1205,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_paginator(queryset, per_page, orphans=0, allow_empty_first_page=True)
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Returns an instance of the paginator to use for this view. By default,
|
||||
instantiates an instance of :attr:`paginator`.
|
||||
|
||||
|
|
@ -1295,8 +1285,6 @@ on your ``ModelAdmin``::
|
|||
}
|
||||
js = ("my_code.js",)
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
The :doc:`staticfiles app </ref/contrib/staticfiles>` prepends
|
||||
:setting:`STATIC_URL` (or :setting:`MEDIA_URL` if :setting:`STATIC_URL` is
|
||||
``None``) to any media paths. The same rules apply as :ref:`regular media
|
||||
|
|
@ -1394,18 +1382,15 @@ adds some of its own (the shared features are actually defined in the
|
|||
- :attr:`~ModelAdmin.exclude`
|
||||
- :attr:`~ModelAdmin.filter_horizontal`
|
||||
- :attr:`~ModelAdmin.filter_vertical`
|
||||
- :attr:`~ModelAdmin.ordering`
|
||||
- :attr:`~ModelAdmin.prepopulated_fields`
|
||||
- :meth:`~ModelAdmin.queryset`
|
||||
- :attr:`~ModelAdmin.radio_fields`
|
||||
- :attr:`~ModelAdmin.readonly_fields`
|
||||
- :attr:`~InlineModelAdmin.raw_id_fields`
|
||||
- :meth:`~ModelAdmin.formfield_for_foreignkey`
|
||||
- :meth:`~ModelAdmin.formfield_for_manytomany`
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
- :attr:`~ModelAdmin.ordering`
|
||||
- :meth:`~ModelAdmin.queryset`
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
- :meth:`~ModelAdmin.has_add_permission`
|
||||
|
|
@ -1813,8 +1798,6 @@ Templates can override or extend base admin templates as described in
|
|||
|
||||
.. attribute:: AdminSite.login_form
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Subclass of :class:`~django.contrib.auth.forms.AuthenticationForm` that
|
||||
will be used by the admin site login view.
|
||||
|
||||
|
|
|
|||
|
|
@ -152,27 +152,6 @@ enable it in your project's ``urls.py``:
|
|||
|
||||
Now you should have the latest comment feeds being served off ``/feeds/latest/``.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
Prior to Django 1.3, the LatestCommentFeed was deployed using the
|
||||
syndication feed view:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from django.conf.urls import patterns
|
||||
from django.contrib.comments.feeds import LatestCommentFeed
|
||||
|
||||
feeds = {
|
||||
'latest': LatestCommentFeed,
|
||||
}
|
||||
|
||||
urlpatterns = patterns('',
|
||||
# ...
|
||||
(r'^feeds/(?P<url>.*)/$', 'django.contrib.syndication.views.feed',
|
||||
{'feed_dict': feeds}),
|
||||
# ...
|
||||
)
|
||||
|
||||
|
||||
Moderation
|
||||
==========
|
||||
|
|
|
|||
|
|
@ -136,10 +136,6 @@ Simply subclassing :class:`CommentModerator` and changing the values of these
|
|||
options will automatically enable the various moderation methods for any
|
||||
models registered using the subclass.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
``moderate_after`` and ``close_after`` now accept 0 as a valid value.
|
||||
|
||||
Adding custom moderation methods
|
||||
--------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -423,8 +423,6 @@ pointing at it will be deleted as well. In the example above, this means that
|
|||
if a ``Bookmark`` object were deleted, any ``TaggedItem`` objects pointing at
|
||||
it would be deleted at the same time.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Unlike :class:`~django.db.models.ForeignKey`,
|
||||
:class:`~django.contrib.contenttypes.generic.GenericForeignKey` does not accept
|
||||
an :attr:`~django.db.models.ForeignKey.on_delete` argument to customize this
|
||||
|
|
|
|||
|
|
@ -239,8 +239,6 @@ template.
|
|||
Getting a list of :class:`~django.contrib.flatpages.models.FlatPage` objects in your templates
|
||||
==============================================================================================
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The flatpages app provides a template tag that allows you to iterate
|
||||
over all of the available flatpages on the :ref:`current site
|
||||
<hooking-into-current-site-from-views>`.
|
||||
|
|
|
|||
|
|
@ -237,8 +237,6 @@ Returns a boolean indicating whether the geometry is valid.
|
|||
|
||||
.. attribute:: GEOSGeometry.valid_reason
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Returns a string describing the reason why a geometry is invalid.
|
||||
|
||||
.. attribute:: GEOSGeometry.srid
|
||||
|
|
@ -535,8 +533,6 @@ corresponding to the SRID of the geometry or ``None``.
|
|||
|
||||
.. method:: GEOSGeometry.transform(ct, clone=False)
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
Transforms the geometry according to the given coordinate transformation paramter
|
||||
(``ct``), which may be an integer SRID, spatial reference WKT string,
|
||||
a PROJ.4 string, a :class:`~django.contrib.gis.gdal.SpatialReference` object, or a
|
||||
|
|
|
|||
|
|
@ -134,8 +134,6 @@ your settings::
|
|||
GeoDjango tests
|
||||
===============
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
GeoDjango's test suite may be run in one of two ways, either by itself or
|
||||
with the rest of :ref:`Django's unit tests <running-unit-tests>`.
|
||||
|
||||
|
|
|
|||
|
|
@ -267,8 +267,6 @@ Austria (``at``)
|
|||
Belgium (``be``)
|
||||
================
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. class:: be.forms.BEPhoneNumberField
|
||||
|
||||
A form field that validates input as a Belgium phone number, with one of
|
||||
|
|
@ -658,11 +656,6 @@ Indonesia (``id``)
|
|||
|
||||
A ``Select`` widget that uses a list of Indonesian provinces as its choices.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The province "Nanggroe Aceh Darussalam (NAD)" has been removed
|
||||
from the province list in favor of the new official designation
|
||||
"Aceh (ACE)".
|
||||
|
||||
.. class:: id.forms.IDPhoneNumberField
|
||||
|
||||
A form field that validates input as an Indonesian telephone number.
|
||||
|
|
|
|||
|
|
@ -330,8 +330,6 @@ with a caching decorator -- you must name your sitemap view and pass
|
|||
Template customization
|
||||
======================
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
If you wish to use a different template for each sitemap or sitemap index
|
||||
available on your site, you may specify it by passing a ``template_name``
|
||||
parameter to the ``sitemap`` and ``index`` views via the URLconf::
|
||||
|
|
|
|||
|
|
@ -159,8 +159,6 @@ the :class:`~django.contrib.sites.models.Site` model's manager has a
|
|||
else:
|
||||
# Do something else.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
For code which relies on getting the current domain but cannot be certain
|
||||
that the sites framework will be installed for any given project, there is a
|
||||
utility function :func:`~django.contrib.sites.models.get_current_site` that
|
||||
|
|
@ -169,12 +167,10 @@ the sites framework is installed) or a RequestSite instance (if it is not).
|
|||
This allows loose coupling with the sites framework and provides a usable
|
||||
fallback for cases where it is not installed.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. function:: get_current_site(request)
|
||||
|
||||
Checks if contrib.sites is installed and returns either the current
|
||||
:class:`~django.contrib.sites.models.Site` object or a
|
||||
:class:`~django.contrib.sites.models.Site` object or a
|
||||
:class:`~django.contrib.sites.models.RequestSite` object based on
|
||||
the request.
|
||||
|
||||
|
|
@ -437,7 +433,7 @@ fallback when the database-backed sites framework is not available.
|
|||
|
||||
Sets the ``name`` and ``domain`` attributes to the value of
|
||||
:meth:`~django.http.HttpRequest.get_host`.
|
||||
|
||||
|
||||
|
||||
A :class:`~django.contrib.sites.models.RequestSite` object has a similar
|
||||
interface to a normal :class:`~django.contrib.sites.models.Site` object, except
|
||||
|
|
|
|||
|
|
@ -5,8 +5,6 @@ The staticfiles app
|
|||
.. module:: django.contrib.staticfiles
|
||||
:synopsis: An app for handling static files.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``django.contrib.staticfiles`` collects static files from each of your
|
||||
applications (and any other places you specify) into a single location that
|
||||
can easily be served in production.
|
||||
|
|
|
|||
|
|
@ -176,8 +176,6 @@ records to dump. If you're using a :ref:`custom manager <custom-managers>` as
|
|||
the default manager and it filters some of the available records, not all of the
|
||||
objects will be dumped.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The :djadminopt:`--all` option may be provided to specify that
|
||||
``dumpdata`` should use Django's base manager, dumping records which
|
||||
might otherwise be filtered or modified by a custom manager.
|
||||
|
|
@ -195,18 +193,10 @@ easy for humans to read, so you can use the ``--indent`` option to
|
|||
pretty-print the output with a number of indentation spaces.
|
||||
|
||||
The :djadminopt:`--exclude` option may be provided to prevent specific
|
||||
applications from being dumped.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The :djadminopt:`--exclude` option may also be provided to prevent specific
|
||||
models (specified as in the form of ``appname.ModelName``) from being dumped.
|
||||
|
||||
In addition to specifying application names, you can provide a list of
|
||||
individual models, in the form of ``appname.Model``. If you specify a model
|
||||
name to ``dumpdata``, the dumped output will be restricted to that model,
|
||||
rather than the entire application. You can also mix application names and
|
||||
model names.
|
||||
applications or models (specified as in the form of ``appname.ModelName``) from
|
||||
being dumped. If you specify a model name to ``dumpdata``, the dumped output
|
||||
will be restricted to that model, rather than the entire application. You can
|
||||
also mix application names and model names.
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database
|
||||
from which data will be dumped.
|
||||
|
|
@ -463,8 +453,6 @@ Use the ``--no-default-ignore`` option to disable the default values of
|
|||
|
||||
.. django-admin-option:: --no-wrap
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Use the ``--no-wrap`` option to disable breaking long message lines into
|
||||
several lines in language files.
|
||||
|
||||
|
|
@ -640,15 +628,11 @@ machines on your network. To make your development server viewable to other
|
|||
machines on the network, use its own IP address (e.g. ``192.168.2.1``) or
|
||||
``0.0.0.0`` or ``::`` (with IPv6 enabled).
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
You can provide an IPv6 address surrounded by brackets
|
||||
(e.g. ``[200a::1]:8000``). This will automatically enable IPv6 support.
|
||||
|
||||
A hostname containing ASCII-only characters can also be used.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
If the :doc:`staticfiles</ref/contrib/staticfiles>` contrib app is enabled
|
||||
(default in new projects) the :djadmin:`runserver` command will be overriden
|
||||
with an own :djadmin:`runserver<staticfiles-runserver>` command.
|
||||
|
|
@ -674,8 +658,6 @@ development server.
|
|||
|
||||
.. django-admin-option:: --ipv6, -6
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Use the ``--ipv6`` (or shorter ``-6``) option to tell Django to use IPv6 for
|
||||
the development server. This changes the default IP address from
|
||||
``127.0.0.1`` to ``::1``.
|
||||
|
|
@ -1113,8 +1095,6 @@ To run on 1.2.3.4:7000 with a ``test`` fixture::
|
|||
|
||||
django-admin.py testserver --addrport 1.2.3.4:7000 test
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The :djadminopt:`--noinput` option may be provided to suppress all user
|
||||
prompts.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Django provides two convenient ways to access the current storage class:
|
|||
.. function:: get_storage_class([import_path=None])
|
||||
|
||||
Returns a class or module which implements the storage API.
|
||||
|
||||
|
||||
When called without the ``import_path`` parameter ``get_storage_class``
|
||||
will return the current default storage system as defined by
|
||||
:setting:`DEFAULT_FILE_STORAGE`. If ``import_path`` is provided,
|
||||
|
|
@ -35,9 +35,9 @@ The FileSystemStorage Class
|
|||
basic file storage on a local filesystem. It inherits from
|
||||
:class:`~django.core.files.storage.Storage` and provides implementations
|
||||
for all the public methods thereof.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
The :class:`FileSystemStorage.delete` method will not raise
|
||||
raise an exception if the given file name does not exist.
|
||||
|
||||
|
|
@ -53,16 +53,12 @@ The Storage Class
|
|||
|
||||
.. method:: accessed_time(name)
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Returns a ``datetime`` object containing the last accessed time of the
|
||||
file. For storage systems that aren't able to return the last accessed
|
||||
time this will raise ``NotImplementedError`` instead.
|
||||
|
||||
.. method:: created_time(name)
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Returns a ``datetime`` object containing the creation time of the file.
|
||||
For storage systems that aren't able to return the creation time this
|
||||
will raise ``NotImplementedError`` instead.
|
||||
|
|
@ -100,8 +96,6 @@ The Storage Class
|
|||
|
||||
.. method:: modified_time(name)
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Returns a ``datetime`` object containing the last modified time. For
|
||||
storage systems that aren't able to return the last modified time, this
|
||||
will raise ``NotImplementedError`` instead.
|
||||
|
|
|
|||
|
|
@ -658,8 +658,6 @@ those classes as an argument::
|
|||
|
||||
.. method:: BoundField.value()
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Use this method to render the raw value of this field as it would be rendered
|
||||
by a ``Widget``::
|
||||
|
||||
|
|
|
|||
|
|
@ -704,8 +704,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
``TypedMultipleChoiceField``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. class:: TypedMultipleChoiceField(**kwargs)
|
||||
|
||||
Just like a :class:`MultipleChoiceField`, except :class:`TypedMultipleChoiceField`
|
||||
|
|
|
|||
|
|
@ -294,11 +294,6 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
|
|||
Determines whether the widget will have a value filled in when the
|
||||
form is re-displayed after a validation error (default is ``False``).
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The default value for
|
||||
:attr:`~PasswordInput.render_value` was
|
||||
changed from ``True`` to ``False``
|
||||
|
||||
``HiddenInput``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -532,8 +527,6 @@ File upload widgets
|
|||
|
||||
.. class:: ClearableFileInput
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
File upload input: ``<input type='file' ...>``, with an additional checkbox
|
||||
input to clear the field's value, if the field is not required and has
|
||||
initial data.
|
||||
|
|
|
|||
|
|
@ -1023,8 +1023,6 @@ define the details of how the relation works.
|
|||
The field on the related object that the relation is to. By default, Django
|
||||
uses the primary key of the related object.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. attribute:: ForeignKey.on_delete
|
||||
|
||||
When an object referenced by a :class:`ForeignKey` is deleted, Django by
|
||||
|
|
|
|||
|
|
@ -505,15 +505,8 @@ followed (optionally) by any output-affecting methods (such as ``values()``),
|
|||
but it doesn't really matter. This is your chance to really flaunt your
|
||||
individualism.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
The ``values()`` method previously did not return anything for
|
||||
:class:`~django.db.models.ManyToManyField` attributes and would raise an error
|
||||
if you tried to pass this type of field to it.
|
||||
|
||||
This restriction has been lifted, and you can now also refer to fields on
|
||||
related models with reverse relations through ``OneToOneField``, ``ForeignKey``
|
||||
and ``ManyToManyField`` attributes::
|
||||
You can also refer to fields on related models with reverse relations through
|
||||
``OneToOneField``, ``ForeignKey`` and ``ManyToManyField`` attributes::
|
||||
|
||||
Blog.objects.values('name', 'entry__headline')
|
||||
[{'name': 'My blog', 'entry__headline': 'An entry'},
|
||||
|
|
@ -1664,10 +1657,9 @@ For example::
|
|||
# This will delete all Blogs and all of their Entry objects.
|
||||
blogs.delete()
|
||||
|
||||
.. versionadded:: 1.3
|
||||
This cascade behavior is customizable via the
|
||||
:attr:`~django.db.models.ForeignKey.on_delete` argument to the
|
||||
:class:`~django.db.models.ForeignKey`.
|
||||
This cascade behavior is customizable via the
|
||||
:attr:`~django.db.models.ForeignKey.on_delete` argument to the
|
||||
:class:`~django.db.models.ForeignKey`.
|
||||
|
||||
The ``delete()`` method does a bulk delete and does not call any ``delete()``
|
||||
methods on your models. It does, however, emit the
|
||||
|
|
|
|||
|
|
@ -42,8 +42,6 @@ All attributes should be considered read-only, unless stated otherwise below.
|
|||
data in different ways than conventional HTML forms: binary images,
|
||||
XML payload etc. For processing conventional form data, use ``HttpRequest.POST``.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
You can also read from an HttpRequest using a file-like interface. See
|
||||
:meth:`HttpRequest.read()`.
|
||||
|
||||
|
|
@ -305,8 +303,6 @@ Methods
|
|||
.. method:: HttpRequest.xreadlines()
|
||||
.. method:: HttpRequest.__iter__()
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Methods implementing a file-like interface for reading from an
|
||||
HttpRequest instance. This makes it possible to consume an incoming
|
||||
request in a streaming fashion. A common use-case would be to process a
|
||||
|
|
@ -509,9 +505,6 @@ In addition, ``QueryDict`` has the following methods:
|
|||
>>> q.urlencode()
|
||||
'a=2&b=3&b=5'
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The ``safe`` parameter was added.
|
||||
|
||||
Optionally, urlencode can be passed characters which
|
||||
do not require encoding. For example::
|
||||
|
||||
|
|
@ -648,12 +641,6 @@ Methods
|
|||
|
||||
.. method:: HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True)
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
The possibility of specifying a ``datetime.datetime`` object in
|
||||
``expires``, and the auto-calculation of ``max_age`` in such case
|
||||
was added. The ``httponly`` argument was also added.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
The default value for httponly was changed from ``False`` to ``True``.
|
||||
|
|
|
|||
|
|
@ -125,8 +125,6 @@ The site-specific user profile model used by this site. See
|
|||
CACHES
|
||||
------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Default::
|
||||
|
||||
{
|
||||
|
|
@ -167,12 +165,6 @@ backend class (i.e. ``mypackage.backends.whatever.WhateverCache``).
|
|||
Writing a whole new cache backend from scratch is left as an exercise
|
||||
to the reader; see the other backends for examples.
|
||||
|
||||
.. note::
|
||||
Prior to Django 1.3, you could use a URI based version of the backend
|
||||
name to reference the built-in cache backends (e.g., you could use
|
||||
``'db://tablename'`` to refer to the database backend). This format has
|
||||
been deprecated, and will be removed in Django 1.5.
|
||||
|
||||
.. setting:: CACHES-KEY_FUNCTION
|
||||
|
||||
KEY_FUNCTION
|
||||
|
|
@ -534,8 +526,6 @@ Only supported for the ``mysql`` backend (see the `MySQL manual`_ for details).
|
|||
TEST_DEPENDENCIES
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Default: ``['default']``, for all databases other than ``default``,
|
||||
which has no dependencies.
|
||||
|
||||
|
|
@ -1262,8 +1252,6 @@ the ``locale`` directory (i.e. ``'/path/to/locale'``).
|
|||
LOGGING
|
||||
-------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Default: A logging configuration dictionary.
|
||||
|
||||
A data structure containing configuration information. The contents of
|
||||
|
|
@ -1278,8 +1266,6 @@ email log handler; all other log messages are given to a NullHandler.
|
|||
LOGGING_CONFIG
|
||||
--------------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Default: ``'django.utils.log.dictConfig'``
|
||||
|
||||
A path to a callable that will be used to configure logging in the
|
||||
|
|
@ -1371,13 +1357,11 @@ MEDIA_URL
|
|||
Default: ``''`` (Empty string)
|
||||
|
||||
URL that handles the media served from :setting:`MEDIA_ROOT`, used
|
||||
for :doc:`managing stored files </topics/files>`.
|
||||
for :doc:`managing stored files </topics/files>`. It must end in a slash if set
|
||||
to a non-empty value.
|
||||
|
||||
Example: ``"http://media.example.com/"``
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
It must end in a slash if set to a non-empty value.
|
||||
|
||||
MESSAGE_LEVEL
|
||||
-------------
|
||||
|
||||
|
|
@ -1896,10 +1880,6 @@ A tuple of callables that are used to populate the context in ``RequestContext``
|
|||
These callables take a request object as their argument and return a dictionary
|
||||
of items to be merged into the context.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
The ``django.core.context_processors.static`` context processor
|
||||
was added in this release.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
The ``django.core.context_processors.tz`` context processor
|
||||
was added in this release.
|
||||
|
|
@ -2160,8 +2140,6 @@ See also :setting:`TIME_ZONE`, :setting:`USE_I18N` and :setting:`USE_L10N`.
|
|||
USE_X_FORWARDED_HOST
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.3.1
|
||||
|
||||
Default: ``False``
|
||||
|
||||
A boolean that specifies whether to use the X-Forwarded-Host header in
|
||||
|
|
|
|||
|
|
@ -118,8 +118,6 @@ Arguments sent with this signal:
|
|||
records in the database as the database might not be in a
|
||||
consistent state yet.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
|
|
@ -155,8 +153,6 @@ Arguments sent with this signal:
|
|||
records in the database as the database might not be in a
|
||||
consistent state yet.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
|
|
@ -183,8 +179,6 @@ Arguments sent with this signal:
|
|||
``instance``
|
||||
The actual instance being deleted.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
|
|
@ -209,8 +203,6 @@ Arguments sent with this signal:
|
|||
Note that the object will no longer be in the database, so be very
|
||||
careful what you do with this instance.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
|
|
@ -271,8 +263,6 @@ Arguments sent with this signal:
|
|||
|
||||
For the ``pre_clear`` and ``post_clear`` actions, this is ``None``.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
TemplateResponse and SimpleTemplateResponse
|
||||
===========================================
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. module:: django.template.response
|
||||
:synopsis: Classes dealing with lazy-rendered HTTP responses.
|
||||
|
||||
|
|
|
|||
|
|
@ -160,11 +160,6 @@ it. Example::
|
|||
>>> t.render(Context({"person": PersonClass2}))
|
||||
"My name is Samantha."
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Previously, only variables that originated with an attribute lookup would
|
||||
be called by the template system. This change was made for consistency
|
||||
across lookup types.
|
||||
|
||||
Callable variables are slightly more complex than variables which only require
|
||||
straight lookups. Here are some things to keep in mind:
|
||||
|
||||
|
|
@ -448,11 +443,6 @@ If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
|
|||
``django.contrib.auth.context_processors.PermWrapper``, representing the
|
||||
permissions that the currently logged-in user has.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Prior to version 1.3, ``PermWrapper`` was located in
|
||||
``django.contrib.auth.context_processors``.
|
||||
|
||||
|
||||
django.core.context_processors.debug
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -491,8 +481,6 @@ django.core.context_processors.static
|
|||
|
||||
.. function:: django.core.context_processors.static
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
|
||||
``RequestContext`` will contain a variable ``STATIC_URL``, providing the
|
||||
value of the :setting:`STATIC_URL` setting.
|
||||
|
|
|
|||
|
|
@ -156,8 +156,6 @@ In this syntax, each value gets interpreted as a literal string, and there's no
|
|||
way to specify variable values. Or literal commas. Or spaces. Did we mention
|
||||
you shouldn't use this syntax in any new projects?
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
By default, when you use the ``as`` keyword with the cycle tag, the
|
||||
usage of ``{% cycle %}`` that declares the cycle will itself output
|
||||
the first value in the cycle. This could be a problem if you want to
|
||||
|
|
@ -676,9 +674,6 @@ including it. This example produces the output ``"Hello, John"``:
|
|||
|
||||
{{ greeting }}, {{ person|default:"friend" }}!
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Additional context and exclusive context.
|
||||
|
||||
You can pass additional context to the template using keyword arguments::
|
||||
|
||||
{% include "name_snippet.html" with person="Jane" greeting="Hello" %}
|
||||
|
|
@ -710,8 +705,6 @@ registered in ``somelibrary`` and ``otherlibrary`` located in package
|
|||
|
||||
{% load somelibrary package.otherlibrary %}
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
You can also selectively load individual filters or tags from a library, using
|
||||
the ``from`` argument. In this example, the template tags/filters named ``foo``
|
||||
and ``bar`` will be loaded from ``somelibrary``::
|
||||
|
|
@ -1076,9 +1069,6 @@ which is rounded up to 88).
|
|||
with
|
||||
^^^^
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
New keyword argument format and multiple variable assignments.
|
||||
|
||||
Caches a complex variable under a simpler name. This is useful when accessing
|
||||
an "expensive" method (e.g., one that hits the database) multiple times.
|
||||
|
||||
|
|
@ -2126,8 +2116,6 @@ For example::
|
|||
If ``value`` is ``"http://www.example.org/foo?a=b&c=d"``, the output will be
|
||||
``"http%3A//www.example.org/foo%3Fa%3Db%26c%3Dd"``.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
An optional argument containing the characters which should not be escaped can
|
||||
be provided.
|
||||
|
||||
|
|
|
|||
|
|
@ -860,8 +860,6 @@ How to log a user out
|
|||
Login and logout signals
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The auth framework uses two :doc:`signals </topics/signals>` that can be used
|
||||
for notification when a user logs in or out.
|
||||
|
||||
|
|
@ -960,8 +958,6 @@ The login_required decorator
|
|||
context variable which stores the redirect path will use the value of
|
||||
``redirect_field_name`` as its key rather than ``"next"`` (the default).
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
:func:`~django.contrib.auth.decorators.login_required` also takes an
|
||||
optional ``login_url`` parameter. Example::
|
||||
|
||||
|
|
@ -1189,9 +1185,6 @@ includes a few other useful built-in views located in
|
|||
that can be used to reset the password, and sending that link to the
|
||||
user's registered email address.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The ``from_email`` argument was added.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
Users flagged with an unusable password (see
|
||||
:meth:`~django.contrib.auth.models.User.set_unusable_password()`
|
||||
|
|
@ -1672,10 +1665,6 @@ The currently logged-in user's permissions are stored in the template variable
|
|||
:class:`django.contrib.auth.context_processors.PermWrapper`, which is a
|
||||
template-friendly proxy of permissions.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Prior to version 1.3, ``PermWrapper`` was located in
|
||||
``django.core.context_processors``.
|
||||
|
||||
In the ``{{ perms }}`` object, single-attribute lookup is a proxy to
|
||||
:meth:`User.has_module_perms <django.contrib.auth.models.User.has_module_perms>`.
|
||||
This example would display ``True`` if the logged-in user had any permissions
|
||||
|
|
@ -1951,8 +1940,6 @@ for example, to control anonymous access.
|
|||
Authorization for inactive users
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
An inactive user is a one that is authenticated but has its attribute
|
||||
``is_active`` set to ``False``. However this does not mean they are not
|
||||
authorized to do anything. For example they are allowed to activate their
|
||||
|
|
|
|||
|
|
@ -51,13 +51,6 @@ Your cache preference goes in the :setting:`CACHES` setting in your
|
|||
settings file. Here's an explanation of all available values for
|
||||
:setting:`CACHES`.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The settings used to configure caching changed in Django 1.3. In
|
||||
Django 1.2 and earlier, you used a single string-based
|
||||
:setting:`CACHE_BACKEND` setting to configure caches. This has
|
||||
been replaced with the new dictionary-based :setting:`CACHES`
|
||||
setting.
|
||||
|
||||
.. _memcached:
|
||||
|
||||
Memcached
|
||||
|
|
@ -83,9 +76,6 @@ two most common are `python-memcached`_ and `pylibmc`_.
|
|||
.. _`python-memcached`: ftp://ftp.tummy.com/pub/python-memcached/
|
||||
.. _`pylibmc`: http://sendapatch.se/projects/pylibmc/
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Support for ``pylibmc`` was added.
|
||||
|
||||
To use Memcached with Django:
|
||||
|
||||
* Set :setting:`BACKEND <CACHES-BACKEND>` to
|
||||
|
|
@ -785,8 +775,6 @@ nonexistent cache key.::
|
|||
Cache key prefixing
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
If you are sharing a cache instance between servers, or between your
|
||||
production and development environments, it's possible for data cached
|
||||
by one server to be used by another server. If the format of cached
|
||||
|
|
@ -807,8 +795,6 @@ collisions in cache values.
|
|||
Cache versioning
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
When you change running code that uses cached values, you may need to
|
||||
purge any existing cached values. The easiest way to do this is to
|
||||
flush the entire cache, but this can lead to the loss of cache values
|
||||
|
|
@ -856,8 +842,6 @@ keys unaffected. Continuing our previous example::
|
|||
Cache key transformation
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
As described in the previous two sections, the cache key provided by a
|
||||
user is not used verbatim -- it is combined with the cache prefix and
|
||||
key version to provide a final cache key. By default, the three parts
|
||||
|
|
@ -878,8 +862,6 @@ be used instead of the default key combining function.
|
|||
Cache key warnings
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Memcached, the most commonly-used production cache backend, does not allow
|
||||
cache keys longer than 250 characters or containing whitespace or control
|
||||
characters, and using such keys will cause an exception. To encourage
|
||||
|
|
@ -966,10 +948,6 @@ mechanism should take into account when building its cache key. For example, if
|
|||
the contents of a Web page depend on a user's language preference, the page is
|
||||
said to "vary on language."
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
In Django 1.3 the full request path -- including the query -- is used
|
||||
to create the cache keys, instead of only the path component in Django 1.2.
|
||||
|
||||
By default, Django's cache system creates its cache keys using the requested
|
||||
path and query -- e.g., ``"/stories/2005/?order_by=author"``. This means every
|
||||
request to that URL will use the same cached version, regardless of user-agent
|
||||
|
|
|
|||
|
|
@ -4,11 +4,6 @@
|
|||
Class-based generic views
|
||||
=========================
|
||||
|
||||
.. note::
|
||||
Prior to Django 1.3, generic views were implemented as functions. The
|
||||
function-based implementation has been removed in favor of the
|
||||
class-based approach described here.
|
||||
|
||||
Writing Web applications can be monotonous, because we repeat certain patterns
|
||||
again and again. Django tries to take away some of that monotony at the model
|
||||
and template layers, but Web developers also experience this boredom at the view
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
Class-based views
|
||||
=================
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
A view is a callable which takes a request and returns a
|
||||
response. This can be more than just a function, and Django provides
|
||||
an example of some classes which can be used as views. These allow you
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
Using mixins with class-based views
|
||||
===================================
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. caution::
|
||||
|
||||
This is an advanced topic. A working knowledge of :doc:`Django's
|
||||
|
|
|
|||
|
|
@ -633,8 +633,6 @@ issue the query::
|
|||
|
||||
>>> Entry.objects.filter(authors__name=F('blog__name'))
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
For date and date/time fields, you can add or subtract a
|
||||
:class:`~datetime.timedelta` object. The following would return all entries
|
||||
that were modified more than 3 days after they were published::
|
||||
|
|
@ -876,7 +874,6 @@ it. For example::
|
|||
# This will delete the Blog and all of its Entry objects.
|
||||
b.delete()
|
||||
|
||||
.. versionadded:: 1.3
|
||||
This cascade behavior is customizable via the
|
||||
:attr:`~django.db.models.ForeignKey.on_delete` argument to the
|
||||
:class:`~django.db.models.ForeignKey`.
|
||||
|
|
|
|||
|
|
@ -242,7 +242,7 @@ By default, the Python DB API will return results without their field
|
|||
names, which means you end up with a ``list`` of values, rather than a
|
||||
``dict``. At a small performance cost, you can return results as a
|
||||
``dict`` by using something like this::
|
||||
|
||||
|
||||
def dictfetchall(cursor):
|
||||
"Returns all rows from a cursor as a dict"
|
||||
desc = cursor.description
|
||||
|
|
@ -256,7 +256,7 @@ Here is an example of the difference between the two::
|
|||
>>> cursor.execute("SELECT id, parent_id from test LIMIT 2");
|
||||
>>> cursor.fetchall()
|
||||
((54360982L, None), (54360880L, None))
|
||||
|
||||
|
||||
>>> cursor.execute("SELECT id, parent_id from test LIMIT 2");
|
||||
>>> dictfetchall(cursor)
|
||||
[{'parent_id': None, 'id': 54360982L}, {'parent_id': None, 'id': 54360880L}]
|
||||
|
|
@ -273,11 +273,6 @@ transaction containing those calls is closed correctly. See :ref:`the
|
|||
notes on the requirements of Django's transaction handling
|
||||
<topics-db-transactions-requirements>` for more details.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
Prior to Django 1.3, it was necessary to manually mark a transaction
|
||||
as dirty using ``transaction.set_dirty()`` when using raw SQL calls.
|
||||
|
||||
Connections and cursors
|
||||
-----------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -66,9 +66,6 @@ database cursor (which is mapped to its own database connection internally).
|
|||
Controlling transaction management in views
|
||||
===========================================
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Transaction management context managers are new in Django 1.3.
|
||||
|
||||
For most people, implicit request-based transactions work wonderfully. However,
|
||||
if you need more fine-grained control over how transactions are managed, you can
|
||||
use a set of functions in ``django.db.transaction`` to control transactions on a
|
||||
|
|
@ -195,8 +192,6 @@ managers, too.
|
|||
Requirements for transaction handling
|
||||
=====================================
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Django requires that every transaction that is opened is closed before
|
||||
the completion of a request. If you are using :func:`autocommit` (the
|
||||
default commit mode) or :func:`commit_on_success`, this will be done
|
||||
|
|
|
|||
|
|
@ -119,8 +119,6 @@ The "From:" header of the email will be the value of the
|
|||
|
||||
This method exists for convenience and readability.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
If ``html_message`` is provided, the resulting email will be a
|
||||
:mimetype:`multipart/alternative` email with ``message`` as the
|
||||
:mimetype:`text/plain` content type and ``html_message`` as the
|
||||
|
|
@ -236,9 +234,6 @@ following parameters (in the given order, if positional arguments are used).
|
|||
All parameters are optional and can be set at any time prior to calling the
|
||||
``send()`` method.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The ``cc`` argument was added.
|
||||
|
||||
* ``subject``: The subject line of the email.
|
||||
|
||||
* ``body``: The body text. This should be a plain text message.
|
||||
|
|
|
|||
|
|
@ -35,19 +35,9 @@ display two blank forms::
|
|||
|
||||
>>> ArticleFormSet = formset_factory(ArticleForm, extra=2)
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
Prior to Django 1.3, formset instances were not iterable. To render
|
||||
the formset you iterated over the ``forms`` attribute::
|
||||
|
||||
>>> formset = ArticleFormSet()
|
||||
>>> for form in formset.forms:
|
||||
... print(form.as_table())
|
||||
|
||||
Iterating over ``formset.forms`` will render the forms in the order
|
||||
they were created. The default formset iterator also renders the forms
|
||||
in this order, but you can change this order by providing an alternate
|
||||
implementation for the :meth:`__iter__()` method.
|
||||
Iterating over the ``formset`` will render the forms in the order they were
|
||||
created. You can change this order by providing an alternate implementation for
|
||||
the :meth:`__iter__()` method.
|
||||
|
||||
Formsets can also be indexed into, which returns the corresponding form. If you
|
||||
override ``__iter__``, you will need to also override ``__getitem__`` to have
|
||||
|
|
|
|||
|
|
@ -195,8 +195,6 @@ return values for dynamic media properties.
|
|||
Paths in media definitions
|
||||
--------------------------
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
Paths used to specify media can be either relative or absolute. If a path
|
||||
starts with ``/``, ``http://`` or ``https://``, it will be interpreted as an
|
||||
absolute path, and left as-is. All other paths will be prepended with the value
|
||||
|
|
|
|||
|
|
@ -117,8 +117,6 @@ middleware is always called on every response.
|
|||
``process_template_response``
|
||||
-----------------------------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. method:: process_template_response(self, request, response)
|
||||
|
||||
``request`` is an :class:`~django.http.HttpRequest` object. ``response`` is a
|
||||
|
|
|
|||
|
|
@ -17,8 +17,6 @@ introduce controlled coupling for convenience's sake.
|
|||
|
||||
.. function:: render(request, template_name[, dictionary][, context_instance][, content_type][, status][, current_app])
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Combines a given template with a given context dictionary and returns an
|
||||
:class:`~django.http.HttpResponse` object with that rendered text.
|
||||
|
||||
|
|
|
|||
|
|
@ -980,13 +980,6 @@ A :class:`ResolverMatch` object can also be assigned to a triple::
|
|||
|
||||
func, args, kwargs = resolve('/some/path/')
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Triple-assignment exists for backwards-compatibility. Prior to
|
||||
Django 1.3, :func:`~django.core.urlresolvers.resolve` returned a
|
||||
triple containing (view function, arguments, keyword arguments);
|
||||
the :class:`ResolverMatch` object (as well as the namespace and pattern
|
||||
information it provides) is not available in earlier Django releases.
|
||||
|
||||
One possible use of :func:`~django.core.urlresolvers.resolve` would be to test
|
||||
whether a view would raise a ``Http404`` error before redirecting to it::
|
||||
|
||||
|
|
|
|||
|
|
@ -80,8 +80,6 @@ Template tags
|
|||
localize
|
||||
~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Enables or disables localization of template variables in the
|
||||
contained block.
|
||||
|
||||
|
|
@ -116,8 +114,6 @@ Template filters
|
|||
localize
|
||||
~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Forces localization of a single value.
|
||||
|
||||
For example::
|
||||
|
|
@ -136,8 +132,6 @@ tag.
|
|||
unlocalize
|
||||
~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Forces a single value to be printed without localization.
|
||||
|
||||
For example::
|
||||
|
|
|
|||
|
|
@ -134,8 +134,6 @@ translations wouldn't be able to reorder placeholder text.
|
|||
Comments for translators
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
If you would like to give translators hints about a translatable string, you
|
||||
can add a comment prefixed with the ``Translators`` keyword on the line
|
||||
preceding the string, e.g.::
|
||||
|
|
@ -255,8 +253,6 @@ cardinality of the elements at play.
|
|||
Contextual markers
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Sometimes words have several meanings, such as ``"May"`` in English, which
|
||||
refers to a month name and to a verb. To enable translators to translate
|
||||
these words correctly in different contexts, you can use the
|
||||
|
|
@ -436,8 +432,6 @@ Localized names of languages
|
|||
|
||||
.. function:: get_language_info
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The ``get_language_info()`` function provides detailed information about
|
||||
languages::
|
||||
|
||||
|
|
@ -535,9 +529,6 @@ using the ``context`` keyword:
|
|||
``blocktrans`` template tag
|
||||
---------------------------
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
New keyword argument format.
|
||||
|
||||
Contrarily to the :ttag:`trans` tag, the ``blocktrans`` tag allows you to mark
|
||||
complex sentences consisting of literals and variable content for translation
|
||||
by making use of placeholders::
|
||||
|
|
@ -664,8 +655,6 @@ string, so they don't need to be aware of translations.
|
|||
translator might translate the string ``"yes,no"`` as ``"ja,nein"``
|
||||
(keeping the comma intact).
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
You can also retrieve information about any of the available languages using
|
||||
provided template tags and filters. To get information about a single language,
|
||||
use the ``{% get_language_info %}`` tag::
|
||||
|
|
@ -787,10 +776,6 @@ directories listed in :setting:`LOCALE_PATHS` have the highest precedence with
|
|||
the ones appearing first having higher precedence than the ones appearing
|
||||
later.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Directories listed in :setting:`LOCALE_PATHS` weren't included in the
|
||||
lookup algorithm until version 1.3.
|
||||
|
||||
Using the JavaScript translation catalog
|
||||
----------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
Logging
|
||||
=======
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. module:: django.utils.log
|
||||
:synopsis: Logging tools for Django applications
|
||||
|
||||
|
|
|
|||
|
|
@ -132,10 +132,6 @@ Now, our ``my_callback`` function will be called each time a request finishes.
|
|||
Note that ``receiver`` can also take a list of signals to connect a function
|
||||
to.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The ``receiver`` decorator was added in Django 1.3.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The ability to pass a list of signals was added.
|
||||
|
|
|
|||
|
|
@ -73,8 +73,6 @@ module defines tests in class-based approach.
|
|||
|
||||
.. admonition:: unittest2
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
Python 2.7 introduced some major changes to the unittest library,
|
||||
adding some extremely useful features. To ensure that every Django
|
||||
project can benefit from these new features, Django ships with a
|
||||
|
|
@ -436,8 +434,6 @@ two databases.
|
|||
Controlling creation order for test databases
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
By default, Django will always create the ``default`` database first.
|
||||
However, no guarantees are made on the creation order of any other
|
||||
databases in your test setup.
|
||||
|
|
@ -1001,8 +997,6 @@ Specifically, a ``Response`` object has the following attributes:
|
|||
The HTTP status of the response, as an integer. See
|
||||
:rfc:`2616#section-10` for a full list of HTTP status codes.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. attribute:: templates
|
||||
|
||||
A list of ``Template`` instances used to render the final content, in
|
||||
|
|
@ -1089,8 +1083,6 @@ The request factory
|
|||
|
||||
.. class:: RequestFactory
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The :class:`~django.test.client.RequestFactory` shares the same API as
|
||||
the test client. However, instead of behaving like a browser, the
|
||||
RequestFactory provides a way to generate a request instance that can
|
||||
|
|
@ -1327,8 +1319,6 @@ This means, instead of instantiating a ``Client`` in each test::
|
|||
Customizing the test client
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. attribute:: TestCase.client_class
|
||||
|
||||
If you want to use a different ``Client`` class (for example, a subclass
|
||||
|
|
@ -1708,8 +1698,6 @@ your test suite.
|
|||
|
||||
.. method:: TestCase.assertQuerysetEqual(qs, values, transform=repr, ordered=True)
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Asserts that a queryset ``qs`` returns a particular list of values ``values``.
|
||||
|
||||
The comparison of the contents of ``qs`` and ``values`` is performed using
|
||||
|
|
@ -1730,8 +1718,6 @@ your test suite.
|
|||
|
||||
.. method:: TestCase.assertNumQueries(num, func, *args, **kwargs)
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Asserts that when ``func`` is called with ``*args`` and ``**kwargs`` that
|
||||
``num`` database queries are executed.
|
||||
|
||||
|
|
@ -1854,8 +1840,6 @@ Skipping tests
|
|||
|
||||
.. currentmodule:: django.test
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The unittest library provides the :func:`@skipIf <unittest.skipIf>` and
|
||||
:func:`@skipUnless <unittest.skipUnless>` decorators to allow you to skip tests
|
||||
if you know ahead of time that those tests are going to fail under certain
|
||||
|
|
|
|||
Loading…
Reference in New Issue