[Trent] > Here is why I really like this idea now. As per usual, any log message call > has the 'msg, *args' arguments. But, in addition, arbitrary objects can be > passed in as keyword arguments. These objects get slapped into the > LogRecord's __dict__ and any subsequent Handler and/or Formatter can work > with those objects. For example, if I want to log some arbitrarily complex > object I can just add it to the log record. On the handling end, I could have > a Formatter that knows how to deal with that object. For formatters that > *don't* recognize certain objects, a reasonable default like using the pprint > module could be used. I like this. I prefer the name "exc_info" (rather than "exc") for the key, as it is clearer that the result of sys.exc_info(), or equivalent, is being passed. How about the following? The kwargs is searched for "exc_info", and if found it is copied to the LogRecord [and removed from kwargs]. The kwargs dict is then bound to a "user_info" attribute of the LogRecord. > Cons: > - The signature ...**kwargs... doesn't make it clear that a special key > for exception info will be handled. Agreed, though spelling this out in the docstring will mitigate this... > - This could be construed as too much generality. It may complicate the > LogRecord and Formatter in that they have to deal with arbitrary keyword > args. (Mind you, I don't think that that needs to be any issue. For a > first pass any keyword arg other than 'exc', or whatever it is called, > could be ignored.) There is a potential minefield here - if we are allowing any logging record to be sent by wire to a remote logger, then the "user_info" needs to go too - and what if something in it can't be pickled? Given that it is really important that the logging system is silent except when explicitly asked to do something by a logging call, exceptions caught in the logging system are generally ignored by design. This means that pickling exceptions would not be raised, and I foresee difficulties for developers... The idea of allowing arbitrary objects into the LogRecord is very powerful and has much to commend it, but I think the pickling problem may need to be solved first. What do you think? 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