Greg Ward wrote:
On 07 September 1999, Guido van Rossum said:
This is a valuable service! Even though I'm sure that it will cause some pain for people who were used to this programming style...
I'm not sure I like the fact that you can't turn it off -- traditionally, Python has had a "no warnings" policy. That has been diluted a bit (python -t prints warnings) but so far it has been the default.
I'm wondering if we should introduce a general '-w' flag to turn on warnings like this (which would subsume -t)? Or perhaps there should be a -W flag ("no warnings") and warnings should be the default?
Yes yes yes! While adding "-w" is a long way from having a comprehensive set of compile-time warnings in place, it at least means that someone is *thinking* about it.
I would recommend no warnings by default, and -Wfeature to add specific types of warnings. This pattern follows that used by gcc (well, gcc has *some* warnings by default). Rather than invent a new set of switches, I'd rather steal an existing semantic :-)
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."
... 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). 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'}
Cheers, -g -- Greg Stein, http://www.lyra.org/