[Vinay] > > It might appear that allowing subclasses of LogRecord is the more natural > > thing to do. But this has the potential to stop me from extending > > LogRecord's functionality in the future, as some new attribute I introduce > > might conflict with the same-named attribute in some user's > > LogRecord-derived class. Since I want to preserve this freedom for myself > > and other maintainers of logging, [Walter] > But you have the same problem with Logger, which is made to be > subclassed. And Logger probably changes more often than LogRecord. Not necessarily. LogRecord is a grab-bag for attributes, I expect more volatility in LogRecord attributes (in the sense that even if I only make a similar number of attribute changes to LogRecord and to Logger, I would expect may more changes by users to LogRecord than to Logger - or at least, I wouldn't be surprised if that were the case). [Vinay] > > > > 1. Use a keyword argument, extra_info=None. You can use this on any call > > such as warn(), debug() etc. just as exc_info is currently used. A passed in > > value would become the extra_info attribute of the LogRecord. [Walter] > This smells to much like extensibility to per-OO way, i.e. simple add a > void *user_data to every struct you have and you're done. It's not necessarily a bad smell. It's analogous to the "inheritance or composition?" question. There are many cases where designers wrongly use inheritance where composition will suffice. > > 2. Use the "msg" parameter, which all logging calls already have, to have > > the semantics such that it is either a format string, or an instance such > > that str(msg) returns the desired format string. For the simple case, just > > pass in a string. For the more complex case, pass an instance - the caller > > can put any state in there that they want. It will not be used by the core > > logging module, except to call __str__() on it for the format string. But it > > can be used by user-derived classes, which will find it in the msg attribute > > of the LogRecord. This might seem "hackish" to some, but it's not really - > > it's just a question of packaging. > > This is more or less the same as 1.: use an (additional) argument, that > will become an attribute of the LogRecord. Yes - a minor variation. [Vinay] > > Slightly OT: There's a lot of people who think that the logging system > > should be a completely generalized system for event generation and > > processing. I've shied away from using a word like "Event", preferring > > "LogRecord" which tries to indicate that this is a focused class for a > > specific job. [Walter] > Even if LogRecord was renamed Event, it would be a "focused class for a > specific job", because it would be logging.Event. But the name is not so > important as the functionality. Yes, but focused for what job? Names *can* be important. I've committed my share of naming boo-boos in the past, and no doubt will in the future. But Event, even when qualified with "logging.", signifies to me a more general construct (e.g. used for more general messaging applications) than a "LogRecord" (used for holding information about a specific error/diagnostic logging event). I suppose LogEvent would be OK, too - I think I just picked LogRecord to echo the PEP. Regards, Vinay _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
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