Removed "Don't do that" from docs and error messages.

It's slightly aggressive and doesn't explain itself.

django/views/generic/base.py

@@ -50,9 +50,10 @@ class View:
         """Main entry point for a request-response process."""
         for key in initkwargs:
             if key in cls.http_method_names:
-                raise TypeError("You tried to pass in the %s method name as a "
-                                "keyword argument to %s(). Don't do that."
-                                % (key, cls.__name__))
+                raise TypeError(
+                    'The method name %s is not accepted as a keyword argument '
+                    'to %s().' % (key, cls.__name__)
+                )
             if not hasattr(cls, key):
                 raise TypeError("%s() received an invalid keyword %r. as_view "
                                 "only accepts arguments that are already "

docs/intro/tutorial03.txt

@@ -125,13 +125,6 @@ view function. The ``:question_id>`` part of the string defines the name that
 will be used to identify the matched pattern, and the ``<int:`` part is a
 converter that determines what patterns should match this part of the URL path.
 
-There's no need to add URL cruft such as ``.html`` -- unless you want to, in
-which case you can do something like this::
-
-    path('polls/latest.html', views.index),
-
-But, don't do that. It's silly.
-
 Write views that actually do something
 ======================================
 

docs/topics/db/managers.txt

@@ -228,9 +228,8 @@ model. In those situations, Django has to be able to see all the objects for
 the model it is fetching, so that *anything* which is referred to can be
 retrieved.
 
-If you override the ``get_queryset()`` method and filter out any rows, Django
-will return incorrect results. Don't do that. A manager that filters results
-in ``get_queryset()`` is not appropriate for use as a base manager.
+Therefore, you should not override ``get_queryset()`` to filter out any rows.
+If you do so, Django will return incomplete results.
 
 .. _calling-custom-queryset-methods-from-manager:
 

docs/topics/i18n/timezones.txt

@@ -495,10 +495,11 @@ Setup
    datetimes safely, their representation should include the UTC offset, or
    their values should be in UTC (or both!).
 
-   Finally, our calendar system contains interesting traps for computers::
+   Finally, our calendar system contains interesting edge cases. For example,
+   you can't always subtract one year directly from a given date::
 
        >>> import datetime
-       >>> def one_year_before(value):       # DON'T DO THAT!
+       >>> def one_year_before(value):  # Wrong example.
        ...     return value.replace(year=value.year - 1)
        >>> one_year_before(datetime.datetime(2012, 3, 1, 10, 0))
        datetime.datetime(2011, 3, 1, 10, 0)
@@ -507,9 +508,9 @@ Setup
        ...
        ValueError: day is out of range for month
 
-   (To implement this function, you must decide whether 2012-02-29 minus
-   one year is 2011-02-28 or 2011-03-01, which depends on your business
-   requirements.)
+   To implement such a function correctly, you must decide whether 2012-02-29
+   minus one year is 2011-02-28 or 2011-03-01, which depends on your business
+   requirements.
 
 #. **How do I interact with a database that stores datetimes in local time?**
 

tests/generic_views/test_base.py

@@ -143,8 +143,8 @@ class ViewTest(SimpleTestCase):
         be named like a HTTP method.
         """
         msg = (
-            "You tried to pass in the %s method name as a keyword argument "
-            "to SimpleView(). Don't do that."
+            'The method name %s is not accepted as a keyword argument to '
+            'SimpleView().'
         )
         # Check each of the allowed method names
         for method in SimpleView.http_method_names: