mirror of
https://github.com/django/django.git
synced 2025-08-04 02:48:35 +00:00
Removed versionadded/changed annotations for 1.9.
This commit is contained in:
Tim Graham
parent
1915a7e5c5
commit
46a38307c2
67 changed files with 15 additions and 731 deletions
|
|
@ -595,13 +595,9 @@ password resets. You must then provide some key implementation details:
|
|||
|
||||
.. admonition:: Importing ``AbstractBaseUser``
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
``AbstractBaseUser`` and ``BaseUserManager`` are importable from
|
||||
``django.contrib.auth.base_user`` so that they can be imported without
|
||||
including ``django.contrib.auth`` in :setting:`INSTALLED_APPS` (this
|
||||
raised a deprecation warning in older versions and is no longer
|
||||
supported in Django 1.9).
|
||||
including ``django.contrib.auth`` in :setting:`INSTALLED_APPS`.
|
||||
|
||||
The following attributes and methods are available on any subclass of
|
||||
:class:`~django.contrib.auth.models.AbstractBaseUser`:
|
||||
|
|
|
|||
|
|
@ -532,8 +532,6 @@ inheritance list.
|
|||
|
||||
.. class:: LoginRequiredMixin
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If a view is using this mixin, all requests by non-authenticated users will
|
||||
be redirected to the login page or shown an HTTP 403 Forbidden error,
|
||||
depending on the
|
||||
|
|
@ -621,8 +619,6 @@ redirects to the login page::
|
|||
|
||||
.. class:: UserPassesTestMixin
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
When using :doc:`class-based views </topics/class-based-views/index>`, you
|
||||
can use the ``UserPassesTestMixin`` to do this.
|
||||
|
||||
|
|
@ -718,11 +714,6 @@ The ``permission_required`` decorator
|
|||
def my_view(request):
|
||||
...
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions, the ``permission`` parameter only worked with
|
||||
strings, lists, and tuples instead of strings and any iterable.
|
||||
|
||||
.. currentmodule:: django.contrib.auth.mixins
|
||||
|
||||
The ``PermissionRequiredMixin`` mixin
|
||||
|
|
@ -733,8 +724,6 @@ To apply permission checks to :doc:`class-based views
|
|||
|
||||
.. class:: PermissionRequiredMixin
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
This mixin, just like the ``permission_required``
|
||||
decorator, checks whether the user accessing a view has all given
|
||||
permissions. You should specify the permission (or an iterable of
|
||||
|
|
@ -775,8 +764,6 @@ user to the login page or issue an HTTP 403 Forbidden response.
|
|||
|
||||
.. class:: AccessMixin
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
.. attribute:: login_url
|
||||
|
||||
Default return value for :meth:`get_login_url`. Defaults to ``None``
|
||||
|
|
@ -1313,10 +1300,6 @@ implementation details see :ref:`using-the-views`.
|
|||
The ``current_app`` parameter is deprecated and will be removed in
|
||||
Django 2.0. Callers should set ``request.current_app`` instead.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``extra_email_context`` parameter was added.
|
||||
|
||||
**Template context:**
|
||||
|
||||
* ``form``: The form (see ``password_reset_form`` above) for resetting
|
||||
|
|
|
|||
|
|
@ -258,10 +258,6 @@ request for a nonexistent user (which runs the default hasher). You may be able
|
|||
to mitigate this by :ref:`upgrading older password hashes
|
||||
<wrapping-password-hashers>`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Passwords updates when changing the number of bcrypt rounds was added.
|
||||
|
||||
.. _wrapping-password-hashers:
|
||||
|
||||
Password upgrading without requiring a login
|
||||
|
|
@ -392,8 +388,6 @@ The corresponding algorithm names are:
|
|||
Writing your own hasher
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 1.9.3
|
||||
|
||||
If you write your own password hasher that contains a work factor such as a
|
||||
number of iterations, you should implement a
|
||||
``harden_runtime(self, password, encoded)`` method to bridge the runtime gap
|
||||
|
|
@ -450,8 +444,6 @@ Password validation
|
|||
|
||||
.. module:: django.contrib.auth.password_validation
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Users often choose poor passwords. To help mitigate this problem, Django
|
||||
offers pluggable password validation. You can configure multiple password
|
||||
validators at the same time. A few validators are included in Django, but it's
|
||||
|
|
|
|||
|
|
@ -804,10 +804,6 @@ You can also pass any callable as a *default* value::
|
|||
>>> cache.get_or_set('some-timestamp-key', datetime.datetime.now)
|
||||
datetime.datetime(2014, 12, 11, 0, 15, 49, 457920)
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``get_or_set()`` method was added.
|
||||
|
||||
There's also a ``get_many()`` interface that only hits the cache once.
|
||||
``get_many()`` returns a dictionary with all the keys you asked for that
|
||||
actually exist in the cache (and haven't expired)::
|
||||
|
|
|
|||
|
|
@ -305,11 +305,6 @@ The decorators will process a request in the order they are passed to the
|
|||
decorator. In the example, ``never_cache()`` will process the request before
|
||||
``login_required()``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ability to use ``method_decorator()`` on a class and the ability for
|
||||
it to accept a list or tuple of decorators were added.
|
||||
|
||||
In this example, every instance of ``ProtectedView`` will have login protection.
|
||||
|
||||
.. note::
|
||||
|
|
|
|||
|
|
@ -899,10 +899,6 @@ the number of deletions per object type. Example::
|
|||
>>> e.delete()
|
||||
(1, {'weblog.Entry': 1})
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The return value describing the number of objects deleted was added.
|
||||
|
||||
You can also delete objects in bulk. Every
|
||||
:class:`~django.db.models.query.QuerySet` has a
|
||||
:meth:`~django.db.models.query.QuerySet.delete` method, which deletes all
|
||||
|
|
@ -924,10 +920,6 @@ object individually) rather than using the bulk
|
|||
:meth:`~django.db.models.query.QuerySet.delete` method of a
|
||||
:class:`~django.db.models.query.QuerySet`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The return value describing the number of objects deleted was added.
|
||||
|
||||
When Django deletes an object, by default it emulates the behavior of the SQL
|
||||
constraint ``ON DELETE CASCADE`` -- in other words, any objects which had
|
||||
foreign keys pointing at the object to be deleted will be deleted along with
|
||||
|
|
|
|||
|
|
@ -254,8 +254,6 @@ something really strange.
|
|||
Performing actions after commit
|
||||
===============================
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Sometimes you need to perform an action related to the current database
|
||||
transaction, but only if the transaction successfully commits. Examples might
|
||||
include a `Celery`_ task, an email notification, or a cache invalidation.
|
||||
|
|
|
|||
|
|
@ -573,11 +573,6 @@ argument - the index of the form in the formset. The index is ``None`` for the
|
|||
... kwargs['custom_kwarg'] = index
|
||||
... return kwargs
|
||||
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``form_kwargs`` argument was added.
|
||||
|
||||
Using a formset in views and templates
|
||||
======================================
|
||||
|
||||
|
|
|
|||
|
|
@ -560,10 +560,6 @@ the field declaratively and setting its ``validators`` parameter::
|
|||
model = Article
|
||||
fields = ['pub_date', 'headline', 'content', 'reporter', 'slug']
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``Meta.field_classes`` attribute was added.
|
||||
|
||||
.. note::
|
||||
|
||||
When you explicitly instantiate a form field like this, it is important to
|
||||
|
|
|
|||
|
|
@ -111,8 +111,3 @@ client-side caching.
|
|||
This decorator adds a ``Cache-Control: max-age=0, no-cache, no-store,
|
||||
must-revalidate`` header to a response to indicate that a page should never
|
||||
be cached.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Before Django 1.9, ``Cache-Control: max-age=0`` was sent. This didn't
|
||||
reliably prevent caching in all browsers.
|
||||
|
|
|
|||
|
|
@ -702,8 +702,6 @@ the next section for details).
|
|||
Extending database-backed session engines
|
||||
=========================================
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Creating a custom database-backed session engine built upon those included in
|
||||
Django (namely ``db`` and ``cached_db``) may be done by inheriting
|
||||
:class:`~base_session.AbstractBaseSession` and either ``SessionStore`` class.
|
||||
|
|
@ -714,7 +712,6 @@ including ``django.contrib.sessions`` in :setting:`INSTALLED_APPS`.
|
|||
|
||||
.. class:: base_session.AbstractBaseSession
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The abstract base session model.
|
||||
|
||||
|
|
@ -751,8 +748,6 @@ You can also customize the model manager by subclassing
|
|||
|
||||
.. class:: base_session.BaseSessionManager
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
.. method:: encode(session_dict)
|
||||
|
||||
Returns the given session dictionary serialized and encoded as a string.
|
||||
|
|
@ -773,14 +768,10 @@ and properties described below:
|
|||
|
||||
.. classmethod:: get_model_class()
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Override this method to return a custom session model if you need one.
|
||||
|
||||
.. method:: create_model_instance(data)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Returns a new instance of the session model object, which represents
|
||||
the current session state.
|
||||
|
||||
|
|
@ -793,8 +784,6 @@ and properties described below:
|
|||
|
||||
.. attribute:: cache_key_prefix
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
A prefix added to a session key to build a cache key string.
|
||||
|
||||
Example
|
||||
|
|
|
|||
|
|
@ -679,12 +679,6 @@ the fully qualified name into parts and then tries the following lookup:
|
|||
setting the current application on the :attr:`request.current_app
|
||||
<django.http.HttpRequest.current_app>` attribute.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Previously, the :ttag:`url` template tag did not use the namespace of the
|
||||
currently resolved view and you had to set the ``current_app`` attribute
|
||||
on the request.
|
||||
|
||||
3. If there is no current application. Django looks for a default
|
||||
application instance. The default application instance is the instance
|
||||
that has an :term:`instance namespace` matching the :term:`application
|
||||
|
|
@ -831,11 +825,3 @@ The instance namespace can be specified using the ``namespace`` argument to
|
|||
:func:`~django.conf.urls.include`. If the instance namespace is not specified,
|
||||
it will default to the included URLconf's application namespace. This means
|
||||
it will also be the default instance for that namespace.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In previous versions, you had to specify both the application namespace
|
||||
and the instance namespace in a single place, either by passing them as
|
||||
parameters to :func:`~django.conf.urls.include` or by including a 3-tuple
|
||||
containing
|
||||
``(<list of url() instances>, <application namespace>, <instance namespace>)``.
|
||||
|
|
|
|||
|
|
@ -700,10 +700,6 @@ In practice you'll use this to get a string you can use in multiple places in a
|
|||
template or so you can use the output as an argument for other template tags or
|
||||
filters.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
The ``asvar`` syntax was added.
|
||||
|
||||
``{% blocktrans %}`` also supports :ref:`contextual
|
||||
markers<contextual-markers>` using the ``context`` keyword:
|
||||
|
||||
|
|
@ -890,10 +886,6 @@ You can then access the information::
|
|||
Bi-directional: {{ lang.bidi }}
|
||||
Name in the active language: {{ lang.name_translated }}
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``name_translated`` attribute was added.
|
||||
|
||||
.. templatetag:: get_language_info_list
|
||||
|
||||
``get_language_info_list``
|
||||
|
|
@ -934,12 +926,6 @@ There are also simple filters available for convenience:
|
|||
* ``{{ LANGUAGE_CODE|language_bidi }}`` (False)
|
||||
* ``{{ LANGUAGE_CODE|language_name_translated }}`` ("německy", when active language is Czech)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``language_name_translated`` filter was added.
|
||||
|
||||
.. _Django templates: ../templates_python/
|
||||
|
||||
Internationalization: in JavaScript code
|
||||
========================================
|
||||
|
||||
|
|
@ -1094,11 +1080,6 @@ If you use more than one ``javascript_catalog`` on a site and some of them
|
|||
define the same strings, the strings in the catalog that was loaded last take
|
||||
precedence.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Before Django 1.9, the catalogs completely overwrote each other and you
|
||||
could only use one at a time.
|
||||
|
||||
The JavaScript translations found in the paths listed in the
|
||||
:setting:`LOCALE_PATHS` setting are also always included. To keep consistency
|
||||
with the translations lookup order algorithm used for Python and templates, the
|
||||
|
|
@ -1304,8 +1285,6 @@ The ``JSONCatalog`` view
|
|||
The ``json_catalog`` view
|
||||
-------------------------
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
.. function:: json_catalog(request, domain='djangojs', packages=None)
|
||||
|
||||
.. deprecated:: 1.10
|
||||
|
|
@ -1769,11 +1748,6 @@ which you ran :djadmin:`django-admin makemessages <makemessages>`, run
|
|||
|
||||
That's it. Your translations are ready for use.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
``compilemessages`` now matches the operation of :djadmin:`makemessages`,
|
||||
scanning the project tree for ``.po`` files to compile.
|
||||
|
||||
.. admonition:: Working on Windows?
|
||||
|
||||
If you're using Windows and need to install the GNU gettext utilities so
|
||||
|
|
|
|||
|
|
@ -292,11 +292,6 @@ verbose as it includes all database queries::
|
|||
},
|
||||
}
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Django's default logging configuration changed. See :ref:`the release notes
|
||||
<default-logging-changes-19>` for a description of the changes.
|
||||
|
||||
Finally, here's an example of a fairly complex logging setup::
|
||||
|
||||
LOGGING = {
|
||||
|
|
@ -504,8 +499,6 @@ Messages to this logger have the following extra context:
|
|||
``django.template``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Log messages related to the rendering of templates.
|
||||
|
||||
* Missing context variables are logged as ``DEBUG`` messages.
|
||||
|
|
@ -753,10 +746,5 @@ Independent of the value of :setting:`DEBUG`:
|
|||
* The :ref:`django-server-logger` logger sends all messages at the ``INFO``
|
||||
level or higher to the console.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Django's default logging configuration changed. See :ref:`the release notes
|
||||
<default-logging-changes-19>` for a description of the changes.
|
||||
|
||||
See also :ref:`Configuring logging <configuring-logging>` to learn how you can
|
||||
complement or replace this default logging configuration.
|
||||
|
|
|
|||
|
|
@ -279,8 +279,6 @@ Initial migrations
|
|||
|
||||
.. attribute:: Migration.initial
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The "initial migrations" for an app are the migrations that create the first
|
||||
version of that app's tables. Usually an app will have just one initial
|
||||
migration, but in some cases of complex model interdependencies it may have two
|
||||
|
|
@ -656,11 +654,6 @@ Django can serialize the following:
|
|||
- Any class reference (must be in module's top-level scope)
|
||||
- Anything with a custom ``deconstruct()`` method (:ref:`see below <custom-deconstruct-method>`)
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Serialization support for ``functools.partial`` and ``LazyObject``
|
||||
instances was added.
|
||||
|
||||
.. versionchanged:: 1.10
|
||||
|
||||
Serialization support for ``enum.Enum`` was added.
|
||||
|
|
|
|||
|
|
@ -206,11 +206,6 @@ Attributes
|
|||
|
||||
A 1-based range iterator of page numbers, e.g. yielding ``[1, 2, 3, 4]``.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions, ``page_range`` returned a list instead of an
|
||||
iterator.
|
||||
|
||||
``InvalidPage`` exceptions
|
||||
==========================
|
||||
|
||||
|
|
|
|||
|
|
@ -216,8 +216,6 @@ This example links the given user with the permission models with PKs 46 and 47.
|
|||
|
||||
.. admonition:: Control characters
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
If the content to be serialized contains control characters that are not
|
||||
accepted in the XML 1.0 standard, the serialization will fail with a
|
||||
:exc:`ValueError` exception. Read also the W3C's explanation of `HTML,
|
||||
|
|
|
|||
|
|
@ -142,10 +142,6 @@ If loading a template fails, the following two exceptions, defined in
|
|||
functions, such as :func:`~django.template.loader.get_template`, that
|
||||
try to load a given template from multiple engines.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``backend``, ``tried``, and ``chain`` arguments were added.
|
||||
|
||||
.. exception:: TemplateSyntaxError(msg)
|
||||
|
||||
This exception is raised when a template was found but contains errors.
|
||||
|
|
@ -374,10 +370,6 @@ applications. This generic name was kept for backwards-compatibility.
|
|||
Tags and filters from built-in libraries can be used without first calling
|
||||
the :ttag:`{% load %} <load>` tag.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``libraries`` and ``builtins`` arguments were added.
|
||||
|
||||
.. module:: django.template.backends.jinja2
|
||||
|
||||
.. class:: Jinja2
|
||||
|
|
@ -515,10 +507,6 @@ See `DEP 182`_ for more information.
|
|||
Debug integration for custom engines
|
||||
------------------------------------
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
Debug page integration for non-Django template engines was added.
|
||||
|
||||
The Django debug page has hooks to provide detailed information when a template
|
||||
error arises. Custom template engines can use these hooks to enhance the
|
||||
traceback information that appears to users. The following hooks are available:
|
||||
|
|
|
|||
|
|
@ -252,8 +252,6 @@ The initial serialization is usually very quick, but if you wish to exclude
|
|||
some apps from this process (and speed up test runs slightly), you may add
|
||||
those apps to :setting:`TEST_NON_SERIALIZED_APPS`.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
To prevent serialized data from being loaded twice, setting
|
||||
``serialized_rollback=True`` disables the
|
||||
:data:`~django.db.models.signals.post_migrate` signal when flushing the test
|
||||
|
|
|
|||
|
|
@ -379,8 +379,6 @@ Use the ``django.test.Client`` class to make requests.
|
|||
|
||||
.. method:: Client.force_login(user, backend=None)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If your site uses Django's :doc:`authentication
|
||||
system</topics/auth/index>`, you can use the ``force_login()`` method
|
||||
to simulate the effect of a user logging into the site. Use this method
|
||||
|
|
@ -461,8 +459,6 @@ Specifically, a ``Response`` object has the following attributes:
|
|||
|
||||
.. method:: json(**kwargs)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The body of the response, parsed as JSON. Extra keyword arguments are
|
||||
passed to :func:`json.loads`. For example::
|
||||
|
||||
|
|
@ -658,8 +654,6 @@ If your tests make any database queries, use subclasses
|
|||
|
||||
.. attribute:: SimpleTestCase.allow_database_queries
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
:class:`~SimpleTestCase` disallows database queries by default. This
|
||||
helps to avoid executing write queries which will affect other tests
|
||||
since each ``SimpleTestCase`` test isn't run in a transaction. If you
|
||||
|
|
@ -824,11 +818,6 @@ By default the live server listens on ``localhost`` and picks the first
|
|||
available port in the ``8081-8179`` range. Its full URL can be accessed with
|
||||
``self.live_server_url`` during the tests.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In earlier versions, the live server's default address was always
|
||||
``'localhost:8081'``.
|
||||
|
||||
If you'd like to select another address, you may pass a different one using the
|
||||
:option:`test --liveserver` option, for example:
|
||||
|
||||
|
|
@ -836,12 +825,6 @@ If you'd like to select another address, you may pass a different one using the
|
|||
|
||||
$ ./manage.py test --liveserver=localhost:8082
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In older versions ``live_server_url`` could only be accessed from an
|
||||
instance. It now is a class property and can be accessed from class methods
|
||||
like ``setUpClass()``.
|
||||
|
||||
Another way of changing the default server address is by setting the
|
||||
`DJANGO_LIVE_TEST_SERVER_ADDRESS` environment variable somewhere in your
|
||||
code (for example, in a :ref:`custom test runner<topics-testing-test_runner>`)::
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue