[Steven Lott] > ouch. That is too cumbersome to be an essential feature. When > debugging a fairly sophisticated class, some methods deserve > their own subjects. This would be awfully complex to create a > channel/logger instance for each interesting method. I'm not suggesting that you need to create a logger for every method. Remember, you can already see which module/file and the line number where the logging call was made. If you wanted more information, you could easily include it in the logging message - this could either be the whole of the subject, or include the subject. > It would be much more useful to have a > A) truly Singleton logger instance. Different people have different needs. You can just use the root logger. Others can create more loggers if they want. > B) the ability to specify subject, severity, etc. as part of > the object being logged; via a simple log.log() method that > accepts an Event instance. A default subject would be used for > people who didn't provide one in the constructor. I understand why some people might like this, but I don't think it's everyone's preferred way of working. The successful logging systems which inspired PEP282 do not force one to instantiate a class for the simple case. My other posts indicate how some support for your needs might be provided, without forcing everyone down the same path. > C) the ability to use method names or arguments to fill in part > of an Event object; log.warn(), for example would fill in the > module-specified warning severity; > log.log(...,severity=logging.WARN) for those who prefer fewer > methods with more options. logging.py already uses convenience methods to fill in the level. Have you looked at the module yet, or am I misunderstanding? > D) the ability to create an Event object out of a standard > Exception instance (filling in subject and severity > automatically) What do you mean by "create out of"? If you mean "inherit from", I disagree, as not all events are logically exceptions (e.g. informational events). If you mean "have as an attribute", then that's supported by existing mechanisms. "Filling in subject and severity automatically" - I can just see a plethora of disagreeing views over what severity should be used for this exception or that. Of course, all of this is possible by building on the core framework. I'd hope I've tried to make "simple things easy, and hard things possible". > E) the ability to construct a "this class" or "this module" > accessor as shown above that would fill in the subject for > people who found the "channel" model helpful. > > Items A-D would be the core logger, maximum flexibility, minimal > implementation. Item E would add a feature to the above model > that some people find useful. If you ask me, logging.py is fairly minimal when compared to (say) log4j. log4j - 24 source files, 7000 lines, over 200Kbytes - core logging + console and file handlers logging.py - 1 source file, under 2000 lines, 7Kbytes, core logging + console, file, socket, datagram, and other handlers. I have considered moving some of the less used loggers out of the core, but even with them in it's still pretty small. No, don't all disagree at once!! Just trying to show off :-) 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