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

git-svn-id: http://code.djangoproject.com/svn/django/trunk@14541 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/releases/1.3-alpha-1.txt

@@ -169,29 +169,27 @@ Backwards-incompatible changes in 1.3 alpha 1
 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.
+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`` .
 
-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::
+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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

docs/releases/1.3.txt

@@ -160,24 +160,21 @@ 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.
+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`` .
 
-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::
+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)