Index: Doc/library/warnings.rst
===================================================================
--- Doc/library/warnings.rst	(revision 77313)
+++ Doc/library/warnings.rst	(working copy)
@@ -59,7 +59,7 @@
 | :exc:`UserWarning`               | The default category for :func:`warn`.        |
 +----------------------------------+-----------------------------------------------+
 | :exc:`DeprecationWarning`        | Base category for warnings about deprecated   |
-|                                  | features.                                     |
+|                                  | features (ignored by default).                |
 +----------------------------------+-----------------------------------------------+
 | :exc:`SyntaxWarning`             | Base category for warnings about dubious      |
 |                                  | syntactic features.                           |
@@ -89,7 +89,10 @@
 standard warning categories.  A warning category must always be a subclass of
 the :exc:`Warning` class.
 
+.. versionchanged:: 2.7
+   :exc:`DeprecationWarning` is ignored by default.
 
+
 .. _warning-filter:
 
 The Warnings Filter
@@ -148,15 +151,7 @@
 :mod:`warnings` module parses these when it is first imported (invalid options
 are ignored, after printing a message to ``sys.stderr``).
 
-The warnings that are ignored by default may be enabled by passing :option:`-Wd`
-to the interpreter. This enables default handling for all warnings, including
-those that are normally ignored by default. This is particular useful for
-enabling ImportWarning when debugging problems importing a developed package.
-ImportWarning can also be enabled explicitly in Python code using::
 
-   warnings.simplefilter('default', ImportWarning)
-
-
 .. _warning-suppress:
 
 Temporarily Suppressing Warnings
@@ -226,6 +221,41 @@
 entries from the warnings list before each new operation).
 
 
+Updating Code For New Versions of Python
+----------------------------------------
+
+By default, the Python interpreter ignores warnings that are only of interest
+to developers. This is done for two reasons. Firstly, a developer does not
+necessarily have control over what interpreter a user runs their code on. It is
+possible that a new version of Python will be released between your release
+cycles that introduces new warnings that your code triggers, e.g. :exc:`DeprecationWarning`
+for a module that you are using. While you as a developer care that your code
+is using a deprecated module, a user does not.
+
+There is also the issue that warnings in Python are triggered during every
+execution. For compiled languages, certain warnings only show up once when code
+is compiled into a binary. Since Python is an interpreted language, warnings
+are emitted each time a code path which contains a warning is executed. For
+this reason, these types of warnings are silent by default.
+
+As a developer, you should make sure to test your code without ignoring
+warnings. From the command-line you can enable warnings that are ignored by
+default by passing :option:`-Wd` to the interpreter (this is shorthand for
+:option:`-W default`). This enables default handling for all warnings,
+including those that are ignored by default. To change what action is taken you
+simply change what argument is passed to :option:`-W`, e.g.
+:option:`-W error`. See the :option:`-W` flag for more details on what is
+possible.
+
+To programmatically do the same as :option:`-Wd`, use::
+
+  warnings.simplefilter('default')
+
+Make sure to execute this code as soon as possible. This prevents the
+registering of what warnings have been raised from unexpectedly influencing how
+future warnings are treated.
+
+
 .. _warning-functions:
 
 Available Functions