>>>>> "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
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