[Python-Dev] Warning Framework (PEP 230)

[Guido van Rossum]

> My opinions:
> 
>  * it should be a built-in or keyword, not a function in "sys". Warning
> is supposed to be as easy as possible so people will do it often.

Disagree.  Warnings are there mostly for the Python system to warn the
Python programmer.  The most heavy use will come from the standard
library, not from user code.

> <irrelevant_aside>sys.argv and sys.stdout annoy me as it is.</>

Too bad.

>  * the term "level" applied to warnings typically means "warning level"
> as in -W1 -W2 -Wall. Proposal: call it "stacklevel" or something.

Good point.

>  * this level idea gives rise to another question. What if I want to see
> the full stack context of a warning? Do I have to implement a whole new
> warning output hook? It seems like I should be able to specify this as a
> command line option alongside the action.

Turn warnings into errors and you'll get a full traceback.  If you
really want a full traceback without exiting, some creative use of
sys._getframe() and the traceback module will probably suit you well.

>  * I prefer ":*:*:" to ":::" for leaving parts of the warning spec out.

I don't.

>  * should there be a sys.formatwarning? What if I want to redirect
> warnings to a socket -- I'd like to use the standard formatting
> machinery. Or vice versa, I might want to change the formatting but not
> override the destination.

Good point.  I'm changing this to:

def showwarning(message, category, filename, lineno, file=None):
    """Hook to frite a warning to a file; replace if you like."""

and

def formatwarning(message, category, filename, lineno):
    """Hook to format a warning the standard way."""

>  * there should be a "RuntimeWarning" -- base category for warnings
> about dubious runtime behaviors (e.g. integer division truncated value)

OK.

>  * it should be possible to strip warnings as an optimization step. That
> may require interpreter and syntax support.

I don't see the point of this.  I think this comes from our different
views on who should issue warnings.

>  * warnings will usually be tied to tests which the user will want to be
> able to optimize out also. (e.g. if __debug__ and type(foo)==StringType:
> warn "Should be Unicode!")
> 
> I propose:
> 
> 	>>> warn conditional, message[, category]

Sorry, this is not worth a new keyword.

> to be very parallel with 
> 
> 	>>> assert conditional, message
> 
> I'm not proposing the use of the assert keyword anymore, but I am trying
> to reuse the syntax for familiarity. Perhaps -Wstrip would strip
> warnings out of the bytecode.

Why?

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