I've got some comments on Walter's suggestion and the various posts responding to it. Most recently, both Holger Krekel and Kevin Butler have made what I think of as reasonable comments. FWIW here are my thoughts: A call to the logging API is essentially a statement by the developer about an "event of interest". The difference between Walter's idea and the current state of PEP282 (and my logging module) focuses on two points of interest: "what happened?" and "how important is it?". In both cases, the "what happened?" part is codified by a message (e.g. "disk full"). The "how important is it?" part is codified in the case of PEP282/logging.py by an integer, and in the case of Walter's idea by a class. This, as I see it, is the core difference. Given that an implementation already exists and is in use by quite a few people, I don't think it's right to make changes of a fundamental nature which would require users to rewrite their code, unless the reason is a *really* good one. (the module is still in an "alpha" stage so I am not dead against making changes of this type; I just need to know what the justification is). So far, I am not sure what benefit switching from the status quo of integer-based levels to class-based levels will give. Certainly, the idea of relative levels of importance of events must be preserved, since severity-based filtering is a key function of logging. This could be in theory be done using the inheritance hierarchy of message classes, but I don't think this is particularly elegant here (though it's fine in "except" clauses). And why bother, when integers do the job quite well? And if you use some level attribute in message classes, what has really been gained by using classes? There is also sometimes a possibility that a user-defined handler or filter might, based on the application context and the configuration selected by a developer, choose to change the severity of an event dynamically. This is fine with integers, less so with classes. (I know you can change the class of an instance dynamically, but I'm sure that instances of assignments to __class__ should not be multiplied beyond necessity. Other approaches such as wrapping exceptions are also possible, but in many cases would just obscure the developer's intention, and seeming like trying to "get around the system".) It's not clear to me that class-based levels are a benefit over integer-based levels. The existing implementation, using integer-based levels, seems to offer all the flexibility mentioned by Holger in his post. For example, expensive formatting operations are deferred until (and only if) needed. Factory methods are in place where necessary to facilitate creating user-defined Loggers, Handlers, Filters and LogRecords (the analogue of the Message class). The present design also makes it much easier for users to define their own levels, which can completely slot in and replace the default levels provided (these are based on log4j's experience and strongly recommended, but sometimes users just have to go their own way - I don't like to be too prescriptive in this kind of area). One more limitation of the class-based level idea surfaces from considering how Python applications play in the wider world. Integer levels map quite easily to Unix syslog, NT event log levels, etc. etc. It's easier to pickle logging events and send them to a remote audience if they're integer based, so you don't need a guarantee that the receiving system has the same classes loaded as the sending system. You can send logging events to non-Python SOAP and HTTP receivers which may not be able to deal with severities in terms of classes. Why, you could even interoperate with log4j! Certainly in the heterogeneous corporate world, interoperability is very important beyond the language level. We don't want to put roadblocks to interoperability which force developers to roll their own solutions. In log4j, levels *are* classes, but they are not used in the same way as Walter/Holger have advocated - they are not part of the exception hierarchy, nor are they treated analogously. So, while not wishing to sound abrupt, and respectful of the sentiments which led Walter to make his suggestion, I say -1 invoking KISS, YAGNI and inconvenience to existing users. I discussed with Trent Mick the gist of my argument, and he is in broad agreement with the views expressed above. 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