On 07 September 1999, Greg Stein said:
Also, I would suggest that there should be some standard internal mechanism for reporting errors rather than just calling 'PySys_WriteStderr()'. Something as simple as this would probably do
Why? Why not just use PySys_WriteStdErr() as your requested function? It can easily determine "oops. no stderr. let's do something else."
Hmm, that makes sense for the "what's the local equivalent of stderr?" determination. Probably that actually belongs in mywrite() (the static function in Python/sysmodule.c that PySys_WriteStdout() and PySys_WriteStderr() both invoke), so that the same thing can be done for stdout and stderr. However, I still think a separate function for printing source-code-based warnings is a good idea. This is mainly so that the association from (filename, line_number, message) to "warning: file %s, line %s: %s" % (filename, line_number, message) is done in *one* place, rather than everywhere a warning message is generated. For instance, platforms that don't have stderr, but instead pop up a window with all your compile-time warnings nicely formatted, could take advantage of knowing the filename and line number separately to nicely format those warnings. (Of course, this argues *against* putting the "what's the local equivalent of stderr?" determination in the low-level mywrite() function... arg...)
Maybe sys.show_warnings? ;-) (Of course, that's assuming a run-time warning system in addition to the compile-time warnings of -t and Skip's patch.)
There is no such thing as run-time vs compile-time warnings. You always have a compiler at run-time, and it can be used at any time. Therefore, you just have "(compilation) warnings" (I could imagine that people will come up with other kinds of warnings once the feature is provided).
Well, currently that's true, since currently Python's only warning is the tab warning from -t -- clearly a compile-time warning. (Is this true? I'm no expert on the internals, but I've certainly not seen any other warnings from Python, and I've included plenty of bugs in my code -- umm, just seeing if it would catch them, yeah that's it...) However, one could certainly envision a world where Python issues runtime warnings. If my time machine were working, I'd zip back and suggest to Guido that mistakes with the % operator should issue warnings rather than raising exceptions. (Ignore the language philosophy issue and presume this would be worthwhile.) There are probably other situations where, ignoring past history and language philosophy, it would make sense to issue a warning and march on ahead rather than blowing up immediately. Sometimes Python has a bit of an itchy trigger finger for that ol' TypeError... Anyways, the focus should probably be on compile-time warnings: I can't think of any major runtime errors offhand that Python currently does *nothing* about, so there's not a great need to go scattering the code with runtime warnings. But they *are* a theoretical possibility, and there *is* a difference with compile-time warnings.
I would suggest sys.warnings be a dictionary.
python -Wbad-return -Wlines-per-func=50
print sys.warnings {'bad-return': None, 'lines-per-func': '50'}
Makes sense -- true to warn (possibly giving some extra meaning to "truth", as in this example), and false to not warn. Or maybe None to not warn, not-None to warn. Of course, if there are only compile-time warnings, then modifying sys.warnings will only affect future imports, execs, evals, etc. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913