[Python-Dev] Warning Framework (PEP 230)

[Barry A. Warsaw]

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

    GvR> I've clarified this now: it returns 1 in either case.  You
    GvR> have to do exception handling in either case.  I'm not
    GvR> telling why -- you don't need to know.  The caller of
    GvR> PyErr_Warn() should not attempt to catch the exception -- if
    GvR> that's your intent, you shouldn't be calling PyErr_Warn().
    GvR> And PyErr_Warn() is complicated enough that it has to allow
    GvR> raising an exception.

Makes sense.

    >> - It would be nice if lineno can be a range specification.
    >> Other matches are based on regexps -- think of this as a line
    >> number regexp.

    GvR> Too much complexity already.

Okay, no biggie I think.

    >> - Why not do setupwarnings() in site.py?

    GvR> See the PEP and the current implementation.  The
    GvR> delayed-loading of the warnings module means that we have to
    GvR> save the -W options as sys.warnoptions.  (This also makes
    GvR> them work when multiple interpreters are used -- they all get
    GvR> the -W options.)

Cool.

    >> - Regexp matching on messages should be case insensitive.

    GvR> Good point!  Done in my version of the code.

Cool.

    >> - The second argument to sys.warn() or PyErr_Warn() can be any
    >> class, right?

    GvR> Almost.  It must be derived from __builtin__.Warning.

__builtin__.Warning == exceptions.Warning, right?

    >> If so, it's easy for me to have my own warning classes.  What
    >> if I want to set up my own warnings filters?  Maybe if `action'
    >> could be a callable as well as a string.  Then in my IDE, I
    >> could set that to "mygui.popupWarningsDialog".

    GvR> No, for that purpose you would override
    GvR> warnings.showwarning().

Cool.

Looks good.
-Barry