PEP: 230
Title: Warning Framework
Author: Guido van Rossum <[email protected]>
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Nov-2000
Python-Version: 2.1
Post-History: 05-Nov-2000


Abstract
========

This PEP proposes a C and Python level API, as well as command
line flags, to issue warning messages and control what happens to
them.  This is mostly based on GvR's proposal posted to python-dev
on 05-Nov-2000, with some ideas (such as using classes to
categorize warnings) merged in from Paul Prescod's
counter-proposal posted on the same date.  Also, an attempt to
implement the proposal caused several small tweaks.


Motivation
==========

With Python 3000 looming, it is necessary to start issuing
warnings about the use of obsolete or deprecated features, in
addition to errors.  There are also lots of other reasons to be
able to issue warnings, both from C and from Python code, both at
compile time and at run time.

Warnings aren't fatal, and thus it's possible that a program
triggers the same warning many times during a single execution.
It would be annoying if a program emitted an endless stream of
identical warnings.  Therefore, a mechanism is needed that
suppresses multiple identical warnings.

It is also desirable to have user control over which warnings are
printed.  While in general it is useful to see all warnings all
the time, there may be times where it is impractical to fix the
code right away in a production program.  In this case, there
should be a way to suppress warnings.

It is also useful to be able to suppress specific warnings during
program development, e.g. when a warning is generated by a piece
of 3rd party code that cannot be fixed right away, or when there
is no way to fix the code (possibly a warning message is generated
for a perfectly fine piece of code).  It would be unwise to offer
to suppress all warnings in such cases: the developer would miss
warnings about the rest of the code.

On the other hand, there are also situations conceivable where
some or all warnings are better treated as errors.  For example,
it may be a local coding standard that a particular deprecated
feature should not be used.  In order to enforce this, it is
useful to be able to turn the warning about this particular
feature into an error, raising an exception (without necessarily
turning all warnings into errors).

Therefore, I propose to introduce a flexible "warning filter"
which can filter out warnings or change them into exceptions,
based on:

- Where in the code they are generated (per package, module, or
 function)

- The warning category (warning categories are discussed below)

- A specific warning message

The warning filter must be controllable both from the command line
and from Python code.


APIs For Issuing Warnings
=========================

- To issue a warning from Python::

     import warnings
     warnings.warn(message[, category[, stacklevel]])

 The category argument, if given, must be a warning category
 class (see below); it defaults to warnings.UserWarning.  This
 may raise an exception if the particular warning issued is
 changed into an error by the warnings filter.  The stacklevel
 can be used by wrapper functions written in Python, like this::

     def deprecation(message):
         warn(message, DeprecationWarning, level=2)

 This makes the warning refer to the deprecation()'s caller,
 rather than to the source of deprecation() itself (since the
 latter would defeat the purpose of the warning message).

- To issue a warning from C::

   int PyErr_Warn(PyObject *category, char *message);

 Return 0 normally, 1 if an exception is raised (either because
 the warning was transformed into an exception, or because of a
 malfunction in the implementation, such as running out of
 memory).  The category argument must be a warning category class
 (see below) or ``NULL``, in which case it defaults to
 ``PyExc_RuntimeWarning``.  When ``PyErr_Warn()`` function returns 1, the
 caller should do normal exception handling.

 The current C implementation of ``PyErr_Warn()`` imports the
 warnings module (implemented in Python) and calls its ``warn()``
 function.  This minimizes the amount of C code that needs to be
 added to implement the warning feature.

 [XXX Open Issue: what about issuing warnings during lexing or
 parsing, which don't have the exception machinery available?]


Warnings Categories
===================

There are a number of built-in exceptions that represent warning
categories.  This categorization is useful to be able to filter
out groups of warnings.  The following warnings category classes
are currently defined:

- ``Warning`` -- this is the base class of all warning category
 classes and it itself a subclass of Exception

- ``UserWarning`` -- the default category for ``warnings.warn()``

- ``DeprecationWarning`` -- base category for warnings about deprecated
 features

- ``SyntaxWarning`` -- base category for warnings about dubious
 syntactic features

- ``RuntimeWarning`` -- base category for warnings about dubious
 runtime features

[XXX: Other warning categories may be proposed during the review
period for this PEP.]

These standard warning categories are available from C as
``PyExc_Warning``, ``PyExc_UserWarning``, etc.  From Python, they are
available in the ``__builtin__`` module, so no import is necessary.

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 Warning class.


The Warnings Filter
===================

The warnings filter control whether warnings are ignored,
displayed, or turned into errors (raising an exception).

There are three sides to the warnings filter:

- The data structures used to efficiently determine the
 disposition of a particular ``warnings.warn()`` or ``PyErr_Warn()``
 call.

- The API to control the filter from Python source code.

- The command line switches to control the filter.

The warnings filter works in several stages.  It is optimized for
the (expected to be common) case where the same warning is issued
from the same place in the code over and over.

First, the warning filter collects the module and line number
where the warning is issued; this information is readily available
through ``sys._getframe()``.

Conceptually, the warnings filter maintains an ordered list of
filter specifications; any specific warning is matched against
each filter specification in the list in turn until a match is
found; the match determines the disposition of the match.  Each
entry is a tuple as follows::

 (category, message, module, lineno, action)

- category is a class (a subclass of ``warnings.Warning``) of which
 the warning category must be a subclass in order to match

- message is a compiled regular expression that the warning
 message must match (the match is case-insensitive)

- module is a compiled regular expression that the module name
 must match

- lineno is an integer that the line number where the warning
 occurred must match, or 0 to match all line numbers

- action is one of the following strings:

 - "error" -- turn matching warnings into exceptions

 - "ignore" -- never print matching warnings

 - "always" -- always print matching warnings

 - "default" -- print the first occurrence of matching warnings
   for each location where the warning is issued

 - "module" -- print the first occurrence of matching warnings
   for each module where the warning is issued

 - "once" -- print only the first occurrence of matching
   warnings

Since the ``Warning`` class is derived from the built-in ``Exception``
class, to turn a warning into an error we simply raise
``category(message)``.


Warnings Output And Formatting Hooks
====================================

When the warnings filter decides to issue a warning (but not when
it decides to raise an exception), it passes the information about
the function ``warnings.showwarning(message, category, filename, lineno)``.
The default implementation of this function writes the warning text
to ``sys.stderr``, and shows the source line of the filename.  It has
an optional 5th argument which can be used to specify a different
file than ``sys.stderr``.

The formatting of warnings is done by a separate function,
``warnings.formatwarning(message, category, filename, lineno)``.  This
returns a string (that may contain newlines and ends in a newline)
that can be printed to get the identical effect of the
``showwarning()`` function.


API For Manipulating Warning Filters
====================================
::

   warnings.filterwarnings(message, category, module, lineno, action)

This checks the types of the arguments, compiles the message and
module regular expressions, and inserts them as a tuple in front
of the warnings filter.

::

   warnings.resetwarnings()

Reset the warnings filter to empty.


Command Line Syntax
===================

There should be command line options to specify the most common
filtering actions, which I expect to include at least:

- suppress all warnings

- suppress a particular warning message everywhere

- suppress all warnings in a particular module

- turn all warnings into exceptions

I propose the following command line option syntax::

   -Waction[:message[:category[:module[:lineno]]]]

Where:

- 'action' is an abbreviation of one of the allowed actions
 ("error", "default", "ignore", "always", "once", or "module")

- 'message' is a message string; matches warnings whose message
 text is an initial substring of 'message' (matching is
 case-insensitive)

- 'category' is an abbreviation of a standard warning category
 class name **or** a fully-qualified name for a user-defined
 warning category class of the form [package.]module.classname

- 'module' is a module name (possibly package.module)

- 'lineno' is an integral line number

All parts except 'action' may be omitted, where an empty value
after stripping whitespace is the same as an omitted value.

The C code that parses the Python command line saves the body of
all -W options in a list of strings, which is made available to
the warnings module as sys.warnoptions.  The warnings module
parses these when it is first imported.  Errors detected during
the parsing of sys.warnoptions are not fatal; a message is written
to sys.stderr and processing continues with the option.

Examples:

``-Werror``
   Turn all warnings into errors

``-Wall``
   Show all warnings

``-Wignore``
   Ignore all warnings

``-Wi:hello``
   Ignore warnings whose message text starts with "hello"

``-We::Deprecation``
   Turn deprecation warnings into errors

``-Wi:::spam:10``
   Ignore all warnings on line 10 of module spam

``-Wi:::spam -Wd:::spam:10``
   Ignore all warnings in module spam except on line 10

``-We::Deprecation -Wd::Deprecation:spam``
   Turn deprecation warnings into errors except in module spam


Open Issues
===========

Some open issues off the top of my head:

- What about issuing warnings during lexing or parsing, which
 don't have the exception machinery available?

- The proposed command line syntax is a bit ugly (although the
 simple cases aren't so bad: ``-Werror``, ``-Wignore``, etc.).  Anybody
 got a better idea?

- I'm a bit worried that the filter specifications are too
 complex.  Perhaps filtering only on category and module (not on
 message text and line number) would be enough?

- There's a bit of confusion between module names and file names.
 The reporting uses file names, but the filter specification uses
 module names.  Maybe it should allow filenames as well?

- I'm not at all convinced that packages are handled right.

- Do we need more standard warning categories?  Fewer?

- In order to minimize the start-up overhead, the warnings module
 is imported by the first call to ``PyErr_Warn()``.  It does the
 command line parsing for ``-W`` options upon import.  Therefore, it
 is possible that warning-free programs will not complain about
 invalid ``-W`` options.


Rejected Concerns
=================

Paul Prescod, Barry Warsaw and Fred Drake have brought up several
additional concerns that I feel aren't critical.  I address them
here (the concerns are paraphrased, not exactly their words):

- Paul: ``warn()`` should be a built-in or a statement to make it easily
 available.

 Response: "from warnings import warn" is easy enough.

- Paul: What if I have a speed-critical module that triggers
 warnings in an inner loop.  It should be possible to disable the
 overhead for detecting the warning (not just suppress the
 warning).

 Response: rewrite the inner loop to avoid triggering the
 warning.

- Paul: What if I want to see the full context of a warning?

 Response: use ``-Werror`` to turn it into an exception.

- Paul: I prefer ":\*:\*:" to ":::" for leaving parts of the warning
 spec out.

 Response: I don't.

- Barry: It would be nice if lineno can be a range specification.

 Response: Too much complexity already.

- Barry: I'd like to add my own warning action.  Maybe if 'action'
 could be a callable as well as a string.  Then in my IDE, I
 could set that to "mygui.popupWarningsDialog".

 Response: For that purpose you would override
 ``warnings.showwarning()``.

- Fred: why do the Warning category classes have to be in
 ``__builtin__``?

 Response: that's the simplest implementation, given that the
 warning categories must be available in C before the first
 ``PyErr_Warn()`` call, which imports the warnings module.  I see no
 problem with making them available as built-ins.


Implementation
==============

Here's a prototype implementation:
http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470

You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.