[Kevin Butler] > My experience suggests we use Vinay's exception( lvl, msg, *args ) > to automagically call sys.exc_info() at different log levels, but including > that change skews the results because of Vinay's shorter comment. :-) [some stuff snipped] > Simple usage & test cases work exactly as they did before, > plus Jeremy & I are very happy with our "advanced" applications, > and the "simple subclass" now just needs to override _log to do > advanced things with other optional arguments. To me, this point gives the kwargs argument an edge over the exception(lvl, ...) approach. > If you can provide a simple standard that supports both simple > and advanced applications with equal facility, and you can save > code by doing it without sacrificing readability, why in the world would > you want to require multiple users to add subclasses that just duplicate > the standard library methods with such a slight change? [Kevin Butler, in a followup mail] > By adding the **kwargs to the convenience methods, > the Logger opens itself to change and enables all subclasses > to extend the interface by overriding _log with more keyword > arguments. Kevin, I think you make some good points. If we use **kwargs, we can lose exception and logException, making the interface simpler. And as for the semantics of "exc_info" - it needn't actually be a sys.exc_info() return value - just a truth value to indicate that the caller wants traceback information in the log. In fact, it might be better to code it this way, so that extensibility is a little less restricted. If I re-implement with **kwargs, and remove exception and logException, does anyone have objections if I release 0.4.1 with these (and other) changes? Regards Vinay
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