django/docs/releases/1.8.txt

============================================
Django 1.8 release notes - UNDER DEVELOPMENT
============================================

Welcome to Django 1.8!

These release notes cover the `new features`_, as well as some `backwards
incompatible changes`_ you'll want to be aware of when upgrading from Django
1.6 or older versions. We've also dropped some features, which are detailed in
:ref:`our deprecation plan <deprecation-removed-in-1.8>`, and we've `begun the
deprecation process for some features`_.

.. _`new features`: `What's new in Django 1.8`_
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.8`_
.. _`begun the deprecation process for some features`: `Features deprecated in 1.8`_

Python compatibility
====================

Like Django 1.7, Django 1.8 requires Python 2.7 or above, though we
**highly recommend** the latest minor release.

What's new in Django 1.8
========================

...

Minor features
~~~~~~~~~~~~~~

:mod:`django.contrib.admin`
^^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.auth`
^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.formtools`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.gis`
^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.messages`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.redirects`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.sessions`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.sitemaps`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.sites`
^^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.staticfiles`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

:mod:`django.contrib.syndication`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* ...

Cache
^^^^^

* ...

Email
^^^^^

* :ref:`Email backends <topic-email-backends>` now support the context manager
  protocol for opening and closing connections.

File Storage
^^^^^^^^^^^^

* ...

File Uploads
^^^^^^^^^^^^

* ...

Forms
^^^^^

* Form widgets now render attributes with a value of ``True`` or ``False``
  as HTML5 boolean attributes.

* The new :meth:`~django.forms.Form.has_error()` method allows checking
  if a specific error has happened.

* If :attr:`~django.forms.Form.required_css_class` is defined on a form, then
  the ``<label>`` tags for required fields will have this class present in its
  attributes.

Internationalization
^^^^^^^^^^^^^^^^^^^^

* ...

Management Commands
^^^^^^^^^^^^^^^^^^^

* :djadmin:`dumpdata` now has the option :djadminopt:`--output` which allows
  specifying the file to which the serialized data is written.

Models
^^^^^^

* ...

Signals
^^^^^^^

* ...

Templates
^^^^^^^^^

* ...

Requests and Responses
^^^^^^^^^^^^^^^^^^^^^^

* ...

Tests
^^^^^

* The ``count`` argument was added to
  :meth:`~django.test.SimpleTestCase.assertTemplateUsed`. This allows you to
  assert that a template was rendered a specific number of times.

Validators
^^^^^^^^^^

* ...

Backwards incompatible changes in 1.8
=====================================

.. warning::

    In addition to the changes outlined in this section, be sure to review the
    :doc:`deprecation plan </internals/deprecation>` for any features that
    have been removed. If you haven't updated your code within the
    deprecation timeline for a given feature, its removal may appear as a
    backwards incompatible change.

* Some operations on related objects such as
  :meth:`~django.db.models.fields.related.RelatedManager.add()` or
  :ref:`direct assignment<direct-assignment>` ran multiple data modifying
  queries without wrapping them in transactions. To reduce the risk of data
  corruption, all data modifying methods that affect multiple related objects
  (i.e. ``add()``, ``remove()``, ``clear()``, and
  :ref:`direct assignment<direct-assignment>`) now perform their data modifying
  queries from within a transaction, provided your database supports
  transactions.

  This has one backwards incompatible side effect, signal handlers triggered
  from these methods are now executed within the method's transaction and
  any exception in a signal handler will prevent the whole operation.

Miscellaneous
~~~~~~~~~~~~~

* ``URLField.to_python`` no longer adds a trailing slash to pathless URLs.

* ``django.contrib.gis`` dropped support for GEOS 3.1 and GDAL 1.6.

.. _deprecated-features-1.8:

Features deprecated in 1.8
==========================

Loading ``cycle`` and ``firstof`` template tags from ``future`` library
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Django 1.6 introduced ``{% load cycle from future %}`` and
``{% load firstof from future %}`` syntax for forward compatibility of the
:ttag:`cycle` and :ttag:`firstof` template tags. This syntax is now deprecated
and will be removed in Django 2.0. You can simply remove the
``{% load ... from future %}`` tags.

``django.conf.urls.patterns()``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the olden days of Django, it was encouraged to reference views as strings
in ``urlpatterns``::

    urlpatterns = patterns('',
        url('^$', 'myapp.views.myview'),
    )

and Django would magically import ``myapp.views.myview`` internally and turn
the string into a real function reference. In order to reduce repetition when
referencing many views from the same module, the ``patterns()`` function takes
a required initial ``prefix`` argument which is prepended to all
views-as-strings in that set of ``urlpatterns``::

    urlpatterns = patterns('myapp.views',
        url('^$', 'myview'),
        url('^other/$', 'otherview'),
    )

In the modern era, we have updated the tutorial to instead recommend importing
your views module and referencing your view functions (or classes) directly.
This has a number of advantages, all deriving from the fact that we are using
normal Python in place of "Django String Magic": the errors when you mistype a
view name are less obscure, IDEs can help with autocompletion of view names,
etc.

So these days, the above use of the ``prefix`` arg is much more likely to be
written (and is better written) as::

    from myapp import views

    urlpatterns = patterns('',
        url('^$', views.myview),
        url('^other/$', views.otherview),
    )

Thus ``patterns()`` serves little purpose and is a burden when teaching new users
(answering the newbie's question "why do I need this empty string as the first
argument to ``patterns()``?"). For these reasons, we are deprecating it.
Updating your code is as simple as ensuring that ``urlpatterns`` is a list of
:func:`django.conf.urls.url` instances. For example::

    from django.conf.urls import url
    from myapp import views

    urlpatterns = [
        url('^$', views.myview),
        url('^other/$', views.otherview),
    ]

``django.test.SimpleTestCase.urls``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The attribute :attr:`SimpleTestCase.urls <django.test.SimpleTestCase.urls>`
for specifying URLconf configuration in tests has been deprecated and will be
removed in Django 2.0. Use :func:`@override_settings(ROOT_URLCONF=...)
<django.test.override_settings>` instead.

``prefix`` argument to :func:`~django.conf.urls.i18n.i18n_patterns`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Related to the previous item, the ``prefix`` argument to
:func:`django.conf.urls.i18n.i18n_patterns` has been deprecated. Simply pass a
list of :func:`django.conf.urls.url` instances instead.

Using an incorrect count of unpacked values in the :ttag:`for` template tag
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Using an incorrect count of unpacked values in :ttag:`for` tag will raise an
exception rather than fail silently in Django 2.0.