Index: django/forms/util.py
===================================================================
--- django/forms/util.py	(revision 9699)
+++ django/forms/util.py	(working copy)
@@ -29,6 +29,9 @@
     def as_text(self):
         return u'\n'.join([u'* %s\n%s' % (k, u'\n'.join([u'  * %s' % force_unicode(i) for i in v])) for k, v in self.items()])
 
+    def __getitem__(self, field):
+        return self.setdefault(field, ErrorList())
+
 class ErrorList(list, StrAndUnicode):
     """
     A collection of errors that knows how to display itself in various formats.
Index: tests/regressiontests/forms/forms.py
===================================================================
--- tests/regressiontests/forms/forms.py	(revision 9699)
+++ tests/regressiontests/forms/forms.py	(working copy)
@@ -707,6 +707,29 @@
 >>> f.cleaned_data['password2']
 u'foo'
 
+Test that you can append errors to a field in the clean() method of a Form. This way you
+can place the error message using a shorter syntax (i.e.: self._errors['fieldname'].append(u'error message'))
+>>> class AppendErrors(Form):
+...    field1 = IntegerField()
+...    field2 = IntegerField()
+...    def clean(self):
+...        if self.cleaned_data['field1'] <= self.cleaned_data['field2']:
+...            self._errors['field1'].append(u"Field1 can't be greater than Field2!")
+...        return self.cleaned_data
+>>> f = AppendErrors()
+>>> f.errors
+{}
+>>> f.errors['field1']
+[]
+>>> f = AppendErrors({'field1': 5, 'field2': 10})
+>>> f.errors
+{'field1': [u"Field1 can't be greater than Field2!"]}
+>>> f.errors['field1']
+[u"Field1 can't be greater than Field2!"]
+>>> f.errors['field2']
+[]
+
+
 # Dynamic construction ########################################################
 
 It's possible to construct a Form dynamically by adding to the self.fields
Index: docs/ref/forms/validation.txt
===================================================================
--- docs/ref/forms/validation.txt	(revision 9699)
+++ docs/ref/forms/validation.txt	(working copy)
@@ -107,11 +107,11 @@
 display itself in different ways. So you can treat ``_errors`` as a dictionary
 mapping field names to lists.
 
-If you want to add a new error to a particular field, you should check whether
-the key already exists in ``self._errors`` or not. If not, create a new entry
-for the given key, holding an empty ``ErrorList`` instance. In either case,
-you can then append your error message to the list for the field name in
-question and it will be displayed when the form is displayed.
+If you want to add a new error to a particular field, you can append your error
+message to the list for the field name in question by using ``append()``.
+Django will check if the key already exists, otherwise it will create an empty
+``ErrorList`` instance. Then the error message will be displayed when the form
+is displayed.
 
 There is an example of modifying ``self._errors`` in the following section.
 
@@ -272,11 +272,9 @@
             subject = cleaned_data.get("subject")
 
             if cc_myself and subject and "help" not in subject:
-                # We know these are not in self._errors now (see discussion
-                # below).
                 msg = u"Must put 'help' in subject when cc'ing yourself."
-                self._errors["cc_myself"] = ErrorList([msg])
-                self._errors["subject"] = ErrorList([msg])
+                self._errors["cc_myself"].append(msg)
+                self._errors["subject"].append(msg)
 
                 # These fields are no longer valid. Remove them from the
                 # cleaned data.
@@ -288,11 +286,9 @@
 
 As you can see, this approach requires a bit more effort, not withstanding the
 extra design effort to create a sensible form display. The details are worth
-noting, however. Firstly, earlier we mentioned that you might need to check if
-the field name keys already exist in the ``_errors`` dictionary. In this case,
-since we know the fields exist in ``self.cleaned_data``, they must have been
-valid when cleaned as individual fields, so there will be no corresponding
-entries in ``_errors``.
+noting, however. Firstly, we mentioned that in order to add errors to the
+fields, you just need to ``append()`` your error message in the ``_errors``
+dictionary.
 
 Secondly, once we have decided that the combined data in the two fields we are
 considering aren't valid, we must remember to remove them from the
