
Hi, Vinay Sajip schrieb:
Jesse's and Armin's comments above epitomise the problem. As far as I know (with Google's help), neither has ever bothered to post on python-list, python-dev, their own blogs or anywhere else what these "issues" with logging are. I agree that nobody did. And there is a reason for it, and that reason is probably something that could be discussed in a separate thread too, because it affects a lof stuff that is currently in the standard libary.
Armin has done a fair job on describing bad points about other parts of the library, and fair points they are, too. Armin did once mention logging in a post about singletons, because logging does contain singletons. However, as far as I know it does not cause problems in practice - I use it with Django on numerous websites and the Tornado webserver of FriendFeed/Facebook uses it too, apparently without the sky falling on its head. I'm sorry for the wait I was expressing my disagreement with design decisions made in the standard library and I would love to change that. One of the biggest griefs I have with how the standard library works it
I looked at the logging library and my point of view is that logging is "broken by design". Eg: you can't fix it without breaking backwards compatibility. that it does not work for me and everytime I discuss that topic with anyone else I immediately get the feedback that "this does not happen in the real world" or "works for me" etc. I consider any kind of shared state a design mistake, no matter if it may work for some people or not, the logging package is no exception. However I have to admit that global loggers appears to be one of the easiest solutions for the problem. If I would have to create my own logging library, I would go a total different part from design to implementation. I would create a system where the "sender" is an arbitrary Python object and the system that handles it would have to check for its own if it may process that message. Only *if* there was any handler that wants to do anything with that message, it would pull the details form the stack and format the message. That also would get rid of the formatters and all the other stuff we currently have and avoids a global registry of loggers. How would I configure a logger in a library then? I library would *never* by default print anything that is logged. Default configurations for the logging system currently are the biggest reason for me to hate that library. Many libraries do not even give you the ability to turn of logging in general, and documentation for the logging system was probably one of the reasons. I don't know when the "NullHandler" example appeared in the docs, but I'm sure it was not there when I started using the logging system. I cannot use logging for anything serious because it is slow, it has shared state that often causes frustration, you cannot delete loggers and much more. Of course I do use logging for libraries because it's the standard and the best we have got. The only reasons (in my opinion) that logging is still around is that it's in the stdlib, not because it's any good. Especially when it comes to highly optimized code in web applications you will quickly discover that half a dozen log calls take up more CPU cycles than the actual application code.
This might sound a bit like a rant, but it's not meant to be - I just speak as find. I'm not overly sensitive to criticism about the logging package; in fact I welcome *constructive* criticism which can help to improve it. All of you, please feel free to head over to Andrii's page to post your criticisms/comments there. I don't know how I could contribute constructive criticism. I'm sorry for that.
Am I expecting too much? I'm afraid you are. It's hard to accept that some people think of your system as "it just sucks", but you can't change that. I know that feeling from some of the stuff I wrote. It's just a little bit worse for you because logging is the standard (and only) one, everybody uses. For the stuff I wrote*, people have choice. If they don't want to use it, they don't have to.
Regards, Armin * external libraries, not distributed as part of Python except for the rather simple "ast" module.