Better description in the release notes of what's going on with the PasswordInput change.

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::

The :class:`~django.forms.PasswordInput` form widget, intended for use

with form fields which represent passwords, accepts a boolean keyword

argument ``render_value`` indicating whether to send its data back to

the browser when displaying a submitted form with errors. Prior to

Django 1.3, this argument defaulted to ``True``, meaning that the

submitted password would be sent back to the browser as part of the

form. Developers who wished to add a bit of additional security by

excluding that value from the redisplayed form could instantiate a

:class:`~django.forms.PasswordInput` passing ``render_value=False`` .

Due to the sensitive nature of passwords, however, Django 1.3 takes

this step automatically; the default value of ``render_value`` is now

``False``, and developers who want the password value returned to the

browser on a submission with errors (the previous behavior) must now

explicitly indicate this. For ezmple::

    class LoginForm(forms.Form):

        username = forms.CharField(max_length=100)

        password = forms.CharField(widget=forms.PasswordInput(render_value=True))

Clearable default widget for FileField

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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::

The :class:`~django.forms.PasswordInput` form widget, intended for use

with form fields which represent passwords, accepts a boolean keyword

argument ``render_value`` indicating whether to send its data back to

the browser when displaying a submitted form with errors. Prior to

Django 1.3, this argument defaulted to ``True``, meaning that the

submitted password would be sent back to the browser as part of the

form. Developers who wished to add a bit of additional security by

excluding that value from the redisplayed form could instantiate a

:class:`~django.forms.PasswordInput` passing ``render_value=False`` .

Due to the sensitive nature of passwords, however, Django 1.3 takes

this step automatically; the default value of ``render_value`` is now

``False``, and developers who want the password value returned to the

browser on a submission with errors (the previous behavior) must now

explicitly indicate this. For ezmple::

    class LoginForm(forms.Form):

        username = forms.CharField(max_length=100)