Python 101: An Intro to logging | Hacker News Reader

Python 101: An Intro to logging

blog.pythonlibrary.org

68 pointsdriscollis16 comments

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.

</rant>

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!

If you totally agree with him you wouldn't have written your own library.

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.

There's a basic tutorial, advanced tutorial and a cookbook. http://docs.python.org/library/logging.html

I'm not sure taking a shot at the parent poster is terribly nice, even if you're doing it as part of a code example.

(Groupthink, ignorance, RTFM? Seriously?)

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.

requests requires urllib3, which depends on httplib and urllib.

I'd secretly hope requests was built on top of socket directly.

If anybody wants to do this, the HTTP protocol parser from node.js is really good, and deliberately easy to embed:

https://github.com/joyent/http-parser

How can urllib be great when it sucks?

I think his point is that it is great because it is bad enough that it forces people use a much nicer library.

"In comparison"

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.

Honestly, I don't see a reason to repeat what Doug Hellman did with Python Module Of The Week a while ago:

http://www.doughellmann.com/PyMOTW/py-modindex.html

His articles are comprehensive (were made into a book). For example, the one on logging is here:

http://www.doughellmann.com/PyMOTW/logging/index.html#module...

You know, I really love the Python posts on here.

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.

Reply on news.ycombinator.com