This page should cover pros and cons of current stdlib logging package.

Pros

• Almost every feature you could want from a logging package is there

Cons

• See below. Vinay made sections of each of the points in the original bulleted list for discussion.

Docs are not complete

False. There is pretty much everything in the docs. If you think something is missing, please, be more specific about the missing stuff.

Docs are too long

True. -- techtonik

• The docs are now rearranged into reference API, tutorials (basic and advanced) and cookbook, so this complaint is not really valid. Earlier it was all in one page, so the complaint was more justified. -- VinaySajip

  • I agree that it became much better structurized than before, but the amount of text that an average user needs to read to completely understand how logging works didn't change. Neither part gives a summary about current problems with logging like the one about libraries below. For that part you really need to read everything, but the chances to find this are low. -- techtonik

Config files are a little bit hard to comprehend

An alternate configuration mechanism is provided by the ZConfig package (PyPI). (Note ZConfig is not a small package to pull in.)

Another alternative is provided by the config package, which is a single module and easy to incorporate into logging. However, what say people to the question of backward compatibility? -- VinaySajip

• So the answer is True, but can't not be changed, because of backward compatibility. -- techtonik

  • Since dictionary-based configuration was added (Python 2.7/3.2, available in older Python versions via dictconfig on PyPI), this is not an issue. You can e.g. use YAML or JSON files for configuration. -- VinaySajip

If you want to suggest an alternative mechanism which uses ConfigParser, please suggest alternatives to the format. -- VinaySajip

I'd rather avoid using config files (for logging) entirely in almost every project I work on. If logging has its own configuration files, that's a smell. If I need configfiles for my project, I'll choose the format I need, and expose the necessary settings to the user coherently, including logging settings. That it has its own configuration file to me is a smell, it suggests configuring in code is too hard, and too necessary. -- JoshuaRodman

• It's not a smell - it's not necessary to use, but allows for easier configuration in some scenarios. You can certainly put other settings in the same file, or have separate files for other settings. I don't know of any convention that limits the number of configuration files in an application to zero or one. -- VinaySajip

API uses camelCase (goes against PEP8 recommendation and most of the stdlib)

PEP8 says - consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

• So True, but can't not be changed, because of backward compatibility. logging2 maybe. -- techtonik

  • It's a low priority right now, unless there's an initiative to ensure the rest of the stdlib is made to conform to PEP8. -- VinaySajip

Rather slow considering the large number of function calls performed internally to check which handler to use

There is no official confirmation, but users report 25% boost in performance after commenting logging stuff. So, this stays to be True until somebody proves otherwise.

• Unfortunately that Stanford post doesn't give any indication of how they used logging calls or how they configured it, so their bare statement does not really give any useful information about logging performance. -- VinaySajip

  • If you doubt that Stanford was right by calling logging to be slow then perhaps stackoverflow page will be more convincing. In short - for iner-loop-like scenarios (the 90% code) hotshot indicated logging was one of the biggest bottlenecks. --techtonik

    • Did you notice the accepted answer to that Stack Overflow question? If you have specific performance problems, please post some code and some numbers. -- VinaySajip

  • Why not to include a performance related chapter into logging docs with a measurement instructions? That will be extremely handy for http://speed.python.org -- techtonik

    • In my view, there's no need to do this. Logging calls are of the order of 10s of microseconds, as indicated in figures on this page. -- VinaySajip

Vinay argues that 'logging can be too slow in some specialised scenarios', and asks people to provide more objective metrics than "lot of function calls". Although we don't speak about specialized scenarios, it would be nice if at least these function calls were counted. There are (very simple) timing test results below.

Is a pain in the arse for working with libraries

Libraries should not output any logging information by default unless explicitly asked to do so. That's why they should not try to configure logging. But on the first call to any log() function logging configures itself automatically. This is only documented in thread safety note for logging.log() function and in logging.basicConfig() (one of the examples why Docs are not complete speculation is not corrent - the docs are there, they are just hard to find). So, if any used library uses logging, you have to configure root logger in your application even if it uses other logging means. -- techtonik

• An application developer who uses libraries needs to configure logging in order to debug library behaviour. The alternative would be for libraries to output potentially copious debug logging information and needing to be explicitly silenced. -- VinaySajip

  • Ok, I removed the rant about logging being too obtrusive to debugging libraries. I don't want to debug these 3rd party libraries. Do I have an option to skip logging configuration in application? I don't even know if those libs are using logging at all. -- techtonik
  • A second question - I am currently debugging Spyder IDE. IDE is a just a set of widgets initiated by a central window, but these are also used independently. How can I setup widget logging to be silent if used standalone and don't affect logging configuration of Spyder if used from the IDE? -- techtonik

    • -- Please don't post such questions here, try Stack Overflow or comp.lang.python. -- VinaySajip

Doesn't have runtime scoping (i.e., log messages handled based on the call stack)

Please give some more details on what you mean here. How exactly would you want to log messages based on the call stack? -- VinaySajip

Difficult to extend log records

LogRecords need to be pickleable to be sent across the wire. You can add arbitrary attributes to LogRecords by using the "extra" keyword parameter to logging calls. Exactly how would you like to extend LogRecords in a way which is difficult at the moment, and why? -- VinaySajip

• Changes in Python3.2 allow more control over LogRecord creation -- VinaySajip

I don't really know what this offers, but I usually prefer to simply add attributes to the python objects if I need to decorate them. Perhaps unconventional, but it feels pythonic to me. -- JoshuaRodman

• Yes, but you don't normally have access to a LogRecord when logging an event, so you can't simply add attributes to it. -- VinaySajip

Difficult to add general context to log messages (e.g., add the request URL to all logging messages during the request)

There's information on this very topic at Adding contextual information to your logging output. Can you provide more details on how the mechanism provided fails to meet your needs? -- VinaySajip

I'd prefer some log-invocation magic for the common cases, like the function name I'm in as a token to be expanded. -- JoshuaRodman

• The funtion name is already available without magic, have you checked the documentation? -- VinaySajip