[Python-Dev] Warning framework

[Guido van Rossum]

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

OK, let's make this a class then.  Just keep exceptions out of it
-- this is a separate, disjoint set of classes.  Let's call this
"warning category".  There will be standard categories and user code
can add categories.

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

OK, let's make this a built-in: warning(category, message).

> > 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?

All of the above.

If I'm a programmer maintaining a piece of code, of course I turn all
warnings into errors and fix them as they occur.

But if I'm using someone else's code that happens to generate
warnings, it's better to disable warnings in that code until its
author has released a fixed version.  I want to be able to be very
specific, so that turning off warnings in 3rd party code doesn't
disable them in my own code.  If the 3rd party code generates a single
warning during normal use at a single location (e.g. if there's one
unconverted integer divide somehwere) then it's best to turn it off
just at that location, so that when I feed it other data which may
trigger other warnings elsewhere I will still get the benefit of the
warnings -- which *may* mean there's something wrong with my data, not
with the 3rd party code.

--Guido van Rossum (home page: http://www.python.org/~guido/)