[Python-Dev] Warning framework
Moshe Zadka <email@example.com>
Tue, 7 Nov 2000 08:58:40 +0200 (IST)
On Mon, 6 Nov 2000, Paul Prescod wrote:
> I like the C-level API.
> I think the "level" argument should be some sort of characterization,
> not a number or enumeration. I think of it as being like an exception --
> just another Python object.
These are completely different things -- both should be there. An
exception doesn't need a level -- it's the highest level possible, saying
"get out of here, fast!". Warnings need both a level and characterization.
Having it a Python class is a nice touch, and keeps it consistent with
the way exceptions use classes for characterization.
> In general, I'm uncomfortable that I don't understand the requirements
> enough. Are warnings something that the average Python programmer sees
> rarely and then immediately goes in to fix the code so they don't see it
> anymore (as compiler warnings are often handled)? Or do we expect most
> Python programs to issue hundreds of warnings unless they are filtered.
> Is filtering something you do constantly or as a partial workaround for
> half-broken code that you can't fix right now?
There are two main sources to copy from here:
gcc: You have -Wall, -Wadd-something, etc. Any warning you do see you
either fix, or surround with a pragma so you don't see this.
You also have -Werror to turn all warnings into errors.
Perl: -w gives runtime warnings for things any saner language would
raise exceptions for. "dereferencing NULL", accessing non-existing
elements in an array, etc. Warnings are serious bugs, and you must
always use them.
Perl: "use strict" and friends: die because of some otherwise perfectly
legal Perl if it's not declared properly.
I'd go for a more gcc-like approach: if you see a warning, you should
either 1. Silence it or 2. Fix it.
Silencing warnings is a serious issue: sometimes the programmer does
no better then the interpreter, and should have the ability to silence
any warning permanently -- otherwise he'll work with -silence_all, and
the benefit is lost.
Moshe Zadka <firstname.lastname@example.org> -- 95855124