[Python-Dev] Warning Framework (PEP 230)

[Paul Prescod]

Guido van Rossum wrote:
> 
> Nobody seems to care much about the warnings PEP so far.  What's up?
> Are you all too busy buying presents for the holidays?  Then get me
> some too, please? :-)

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.
<irrelevant_aside>sys.argv and sys.stdout annoy me as it is.</>

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

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

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

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

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

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

 * 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]

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.

 Paul Prescod