Logging is the worst kind of Python standard-library module: too clunky and ugly to be pleasant, but not bad enough to justify the breakage of using a third-party alternative. In comparison, urllib and urllib2 are great, because they suck so much that everybody just uses requests instead.
I totally agree with you. In fact, that's why I wrote an alternative logging library — to try to do the same thing for `logging` that `requests` did for `urllib`. Feel free to check it out: https://github.com/peterldowns/lggr
EDIT: Forgot to mention that although I haven't worked on this for a couple of months, I'm about to revisit it and would love to have other contributors. Please, fork this and make it better!
Slightly pedantic, but you're correct. I meant that he's right that the standard logging library sucks. I guess I think it sucks more than he does, though, becuase I did write my own library.
What's so clunky? It scales nicely. Simplest thing just works, when you need more, you can learn just enough to get what you want.
import logging as log
log.warning("groupthink says it sucks")
log.error("omg wtf, so hard!!!")
log.basicConfig(filename='ignorance.log',level=log.DEBUG)
log.debug("rtfm", exc_info=True)
And so on; formatting, handlers, multiple loggers, config files, proper lib logging, etc. All very pluggable and extendable, but only if you need it.
That's a shot at the many people posting here and elsewhere about how "horrible" logging module is. Most of whom I suspect (cause it ain't that bad) are jumping on the hatewagon without actual investigation of the module.
One extremely useful method that I almost never see in tutorials is
>>> logging.exception("an exception happened here and will be printed")
This will print out the message and then the full formatted error traceback. In many of my old projects I built a whole string formatting mess that would print out and format exceptions and just recently discovered that logging.exception() does that all for you.
I would add 3 (three!) things which either are not covered in the article or (worse) are mis-handled.
1. `exc_info`. The truth is that `logging.exception(message)` is roughly equivalent to `logging.error(message, exc_info=True)`. Now it also expresses intent more clearly so it is a fine method, but what if you want to log an exception at DEBUG level (because it's not an error and you have some sort of fallback)?
logging.debug(message, exc_info=True)
will do that for you (note: it should only used from within an `except` clause)
2. Do not perform string formatting calls in your logging call, let the library do it, just provide the parameters. Instead of TFA's
logging.info("added %s and %s to get %s" % (x, y, x+y))
write
logging.info("added %s and %s to get %s", x, y, x+y)
it's slightly less verbose, and it lets `logging` not to the formatting at all if it does not need to
3. Last, but not least, if you're trying to log expensive-to-fetch information, use `Logger.isEnabledFor(level)` e.g.
if logger.isEnabledFor(logging.DEBUG):
logger.debug("Something: %s", super_expensive_call())
that avoids `super_expensive_call()` if the current logging configuration would not lead to `debug` messages being broadcast for the logger.
Obviously there is a (hard-to-get-to) search function here. But it would be cool if you could set up like newslists or something for certain keywords in post titles, such as Python, etc.
</rant>