[Python-Dev] Warning framework

[Paul Prescod]

Guido van Rossum wrote:
> 
> Before I fall asleep let me write up my ideas about the warning
> framework.
> 
> Requirements:
> 
> - A C-level API that lets C code issue a warning with a single call
>   taking one or two arguments, e.g. Py_Warning(level, message).  (The
>   'level' argument is an example only; I'm not sure what if any we
>   need.)

I like the C-level API.

I think the "level" argument should be some sort of characterization,
not a number or enumeration. I think of it as being like an exception --
just another Python object.

Or it could be just a string. The main point is that filtering on a
number or enum is not flexible enough.

> - An equivalent Python level API, e.g. sys.warning(level, message).

I would prefer something easier to spell and with more of a central "you
should use this alot" feeling.

> Possible implementation:
> 
> - Each module can has a dictionary __warnings__ in its global
>   __dict__, which records the state of warnings.  It is created as an
>   emprt dict if it doesn't exist when it is needed.  The keys are
>   (message, linenumber) tuples (the module or file is implicit through
>   the use of the module's __dict__).  The value is None if no more
>   action is needed for this particular warning and location.  Some
>   other values may indicate the options "always print warning" (1?)
>   and "raise an exception" (-1?).

The problem with filtering based on line number is that it can't really
be done in a static manner because it is too fragile to code changes. In
my proposal every warning was assigned a "type" which would be the key
for filtering. A string would also be fine.

In general, I'm uncomfortable that I don't understand the requirements
enough. Are warnings something that the average Python programmer sees
rarely and then immediately goes in to fix the code so they don't see it
anymore (as compiler warnings are often handled)? Or do we expect most
Python programs to issue hundreds of warnings unless they are filtered.
Is filtering something you do constantly or as a partial workaround for
half-broken code that you can't fix right now?
-- 
 Paul Prescod
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html