django1/docs/releases/1.3.txt

============================================
Django 1.3 release notes - UNDER DEVELOPMENT
============================================

This page documents release notes for the as-yet-unreleased Django
1.3. As such, it's tentative and subject to change. It provides
up-to-date information for those who are following trunk.

Django 1.3 includes a number of nifty `new features`_, lots of bug
fixes and an easy upgrade path from Django 1.2.

.. _new features: `What's new in Django 1.3`_

.. _backwards-incompatible-changes-1.3:

Backwards-incompatible changes in 1.3
=====================================

PasswordInput default rendering behavior
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Prior to Django 1.3, a :class:`~django.forms.PasswordInput` would render
data values like any other form. If a form submission raised an error,
the password that was submitted would be reflected to the client as form
data populating the form for resubmission.

This had the potential to leak passwords, as any failed password
attempt would cause the password that was typed to be sent back to the
client.

In Django 1.3, the default behavior of
:class:`~django.forms.PasswordInput` is to suppress the display of
password values. This change doesn't alter the way form data is
validated or handled. It only affects the user experience with
passwords on a form when they make an error submitting form data (such
as on unsuccessful logins, or when completing a registration form).

If you want restore the pre-Django 1.3 behavior, you need to pass in a
custom widget to your form that sets the ``render_value`` argument::

    class LoginForm(forms.Form):
        username = forms.CharField(max_length=100)
        password = forms.PasswordField(widget=forms.PasswordInput(render_value=True))

Clearable default widget for FileField
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Django 1.3 now includes a ``ClearableFileInput`` form widget in addition to
``FileInput``. ``ClearableFileInput`` renders with a checkbox to clear the
field's value (if the field has a value and is not required); ``FileInput``
provided no means for clearing an existing file from a ``FileField``.

``ClearableFileInput`` is now the default widget for a ``FileField``, so
existing forms including ``FileField`` without assigning a custom widget will
need to account for the possible extra checkbox in the rendered form output.

To return to the previous rendering (without the ability to clear the
``FileField``), use the ``FileInput`` widget in place of
``ClearableFileInput``. For instance, in a ``ModelForm`` for a hypothetical
``Document`` model with a ``FileField`` named ``document``::

    from django import forms
    from myapp.models import Document

    class DocumentForm(forms.ModelForm):
        class Meta:
            model = Document
            widgets = {'document': forms.FileInput}

.. _deprecated-features-1.3:

Features deprecated in 1.3
==========================

Django 1.3 deprecates some features from earlier releases.
These features are still supported, but will be gradually phased out
over the next few release cycles.

Code taking advantage of any of the features below will raise a
``PendingDeprecationWarning`` in Django 1.3. This warning will be
silent by default, but may be turned on using Python's `warnings
module`_, or by running Python with a ``-Wd`` or `-Wall` flag.

.. _warnings module: http://docs.python.org/library/warnings.html

In Django 1.4, these warnings will become a ``DeprecationWarning``,
which is *not* silent. In Django 1.5 support for these features will
be removed entirely.

.. seealso::

    For more details, see the documentation :doc:`Django's release process
    </internals/release-process>` and our :doc:`deprecation timeline
    </internals/deprecation>`.`

``mod_python`` support
~~~~~~~~~~~~~~~~~~~~~~

The ``mod_python`` library has not had a release since 2007 or a commit since
2008. The Apache Foundation board voted to remove ``mod_python`` from the set
of active projects in its version control repositories, and its lead developer
has shifted all of his efforts toward the lighter, slimmer, more stable, and
more flexible ``mod_wsgi`` backend.

If you are currently using the ``mod_python`` request handler, it is strongly
encouraged you redeploy your Django instances using :doc:`mod_wsgi
</howto/deployment/modwsgi>`.

Test client response ``template`` attribute
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Django's :ref:`test client <test-client>` returns
:class:`~django.test.client.Response` objects annotated with extra testing
information. In Django versions prior to 1.3, this included a
:attr:`~django.test.client.Response.template` attribute containing information
about templates rendered in generating the response: either None, a single
:class:`~django.template.Template` object, or a list of
:class:`~django.template.Template` objects. This inconsistency in return values
(sometimes a list, sometimes not) made the attribute difficult to work with.

In Django 1.3 the :attr:`~django.test.client.Response.template` attribute is
deprecated in favor of a new :attr:`~django.test.client.Response.templates`
attribute, which is always a list, even if it has only a single element or no
elements.

What's new in Django 1.3
========================

Logging
~~~~~~~

Django 1.3 adds framework-level support for Python's logging module.
This means you can now easily configure and control logging as part of
your Django project. A number of logging handlers and logging calls
have been added to Django's own code as well -- most notably, the
error emails sent on a HTTP 500 server error are now handled as a
logging activity. See :doc:`the documentation on Django's logging
interface </topics/logging>` for more details.

``unittest2`` support
~~~~~~~~~~~~~~~~~~~~~

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
copy of unittest2_, a copy of the Python 2.7 unittest library,
backported for Python 2.4 compatibility.

To access this library, Django provides the
``django.utils.unittest`` module alias. If you are using Python
2.7, or you have installed unittest2 locally, Django will mapt the
alias to the installed version of the unittest library Otherwise,
Django will use it's own bundled version of unittest2.

To use this alias, simply use::

    from django.utils import unittest

wherever you would historically used::

    import unittest

If you want to continue to use the base unittest libary, you can --
you just won't get any of the nice new unittest2 features.

.. _unittest2: http://pypi.python.org/pypi/unittest2