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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4