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

Pros

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

Cons

• Docs are not complete
• 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.)

• API uses camelCase (goes against PEP8 recommendation and most of the stdlib)
• Rather slow considering the large number of function calls performed internally to check which handler to use
• Doesn't have runtime scoping (i.e., log messages handled based on the call stack)
• Difficult to extend log records
• Difficult to add general context to log messages (e.g., add the request URL to all logging messages during the request)
• By default it does nothing; basicConfig makes it do something but makes it hard to tweak logging.
• filters are an abstract class instead of callables
• Thread-local handlers aren't easy to setup
• Nothing like keywords or tags for doing multi-dimensional categorization or grouping of messages
• No clear way to introduce HTML-formatted messages (or an HTML formatting option)
• Not fast enough to do pervasive logging in libraries (we've encountered this with Paste/Pylons, where we'd like to put lots of logging in that people could turn on, but it becomes a notable performance hit).
• Too complicated, with logging levels, namespaces, handlers, and other things -- they took all the terrible things from java.util.logging and log4j, which are incredibly slow (but powerful) in python.