diff options
author | Benjamin Peterson <benjamin@python.org> | 2010-06-28 00:01:59 (GMT) |
---|---|---|
committer | Benjamin Peterson <benjamin@python.org> | 2010-06-28 00:01:59 (GMT) |
commit | 7ab4b8d3a2e7e91f742a1339a5b8d2988f4b81b6 (patch) | |
tree | 940fba46823c8435d0ffd637e48ef49d7a83bf02 /Doc/library/warnings.rst | |
parent | f23e3744412ac8943bddaace3dc0e85522518319 (diff) | |
download | cpython-7ab4b8d3a2e7e91f742a1339a5b8d2988f4b81b6.zip cpython-7ab4b8d3a2e7e91f742a1339a5b8d2988f4b81b6.tar.gz cpython-7ab4b8d3a2e7e91f742a1339a5b8d2988f4b81b6.tar.bz2 |
Merged revisions 77402,77505,77510 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77402 | brett.cannon | 2010-01-09 20:56:19 -0600 (Sat, 09 Jan 2010) | 12 lines
DeprecationWarning is now silent by default.
This was originally suggested by Guido, discussed on the stdlib-sig mailing
list, and given the OK by Guido directly to me. What this change essentially
means is that Python has taken a policy of silencing warnings that are only
of interest to developers by default. This should prevent users from seeing
warnings which are triggered by an application being run against a new
interpreter before the app developer has a chance to update their code.
Closes issue #7319. Thanks to Antoine Pitrou, Ezio Melotti, and Brian Curtin
for helping with the issue.
........
r77505 | brett.cannon | 2010-01-14 14:00:28 -0600 (Thu, 14 Jan 2010) | 7 lines
The silencing of DeprecationWarning was not taking -3 into consideration. Since
Py3K warnings are DeprecationWarning by default this was causing -3 to
essentially be a no-op. Now DeprecationWarning is only silenced if -3 is not
used.
Closes issue #7700. Thanks Ezio Melotti and Florent Xicluna for patch help.
........
r77510 | brett.cannon | 2010-01-14 19:31:45 -0600 (Thu, 14 Jan 2010) | 1 line
Remove C++/C99-style comments.
........
Diffstat (limited to 'Doc/library/warnings.rst')
-rw-r--r-- | Doc/library/warnings.rst | 44 |
1 files changed, 35 insertions, 9 deletions
diff --git a/Doc/library/warnings.rst b/Doc/library/warnings.rst index 67d93fa..ede991d 100644 --- a/Doc/library/warnings.rst +++ b/Doc/library/warnings.rst @@ -57,7 +57,7 @@ following warnings category classes are currently defined: | :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. | @@ -91,6 +91,9 @@ User code can define additional warning categories by subclassing one of the 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: @@ -150,14 +153,6 @@ interpreter command line. The interpreter saves the arguments for all :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: @@ -233,6 +228,37 @@ continues to increase after each operation, or else delete the previous entries from the warnings list before each new operation). +Updating Code For New Versions of Python +---------------------------------------- + +Warnings that are only of interest to the developer are ignored by default. As +such you should make sure to test your code with typically ignored warnings +made visible. You can do this from the command-line 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 for encountered warnings 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. + +Having certain warnings ignored by default is done to prevent a user from +seeing warnings that are only of interest to the developer. As you do not +necessarily have control over what interpreter a user uses to run their code, +it is possible that a new version of Python will be released between your +release cycles. The new interpreter release could trigger new warnings in your +code that were not there in an older interpreter, e.g. +:exc:`DeprecationWarning` for a module that you are using. While you as a +developer want to be notified that your code is using a deprecated module, to a +user this information is essentially noise and provides no benefit to them. + + .. _warning-functions: Available Functions |