For simple debugging in a complex project is there a reason to use the python logger instead of print? What about other use-cases? Is there an accepted best use-case for each (especially when you’re only looking for stdout)?

I’ve always heard that this is a “best practice” but I haven’t been able to figure out why.

The logging package has a lot of useful features:

• Easy to see where and when (even what line no.) a logging call is being made from.
• You can log to files, sockets, pretty much anything, all at the same time.
• You can differentiate your logging based on severity.

Print doesn’t have any of these.

Also, if your project is meant to be imported by other python tools, it’s bad practice for your package to print things to stdout, since the user likely won’t know where the print messages are coming from. With logging, users of your package can choose whether or not they want to propogate logging messages from your tool or not.

One of the biggest advantages of proper logging is that you can categorize messages and turn them on or off depending on what you need. For example, it might be useful to turn on debugging level messages for a certain part of the project, but tone it down for other parts, so as not to be taken over by information overload and to easily concentrate on the task for which you need logging.

Also, logs are configurable. You can easily filter them, send them to files, format them, add timestamps, and any other things you might need on a global basis. Print statements are not easily managed.

Print statements are sort of the worst of both worlds, combining the negative aspects of an online debugger with diagnostic instrumentation. You have to modify the program but you don’t get more, useful code from it.

An online debugger allows you to inspect the state of a running program; But the nice thing about a real debugger is that you don’t have to modify the source; neither before nor after the debugging session; You just load the program into the debugger, tell the debugger where you want to look, and you’re all set.

Instrumenting the application might take some work up front, modifying the source code in some way, but the resulting diagnostic output can have enormous amounts of detail, and can be turned on or off to a very specific degree. The python logging module can show not just the message logged, but also the file and function that called it, a traceback if there was one, the actual time that the message was emitted, and so on. More than that; diagnostic instrumentation need never be removed; It’s just as valid and useful when the program is finished and in production as it was the day it was added; but it can have it’s output stuck in a log file where it’s not likely to annoy anyone, or the log level can be turned down to keep all but the most urgent messages out.

anticipating the need or use for a debugger is really no harder than using ipython while you’re testing, and becoming familiar with the commands it uses to control the built in pdb debugger.

When you find yourself thinking that a print statement might be easier than using pdb (as it often is), You’ll find that using a logger pulls your program in a much easier to work on state than if you use and later remove print statements.

I have my editor configured to highlight print statements as syntax errors, and logging statements as comments, since that’s about how I regard them.

If you use logging then the person responsible for deployment can configure the logger to send it to a custom location, with custom information. If you only print, then that’s all they get.

Logging essentially creates a searchable plain text database of print outputs with other meta data (timestamp, loglevel, line number, process etc.).

This is pure gold, I can run egrep over the log file after the python script has run. I can tune my egrep pattern search to pick exactly what I am interested in and ignore the rest. This reduction of cognitive load and freedom to pick my egrep pattern later on by trial and error is the key benefit for me.

tail -f mylogfile.log | egrep "key_word1|key_word2"

Now throw in other cool things that print can’t do (sending to socket, setting debug levels, logrotate, adding meta data etc.), you have every reason to prefer logging over plain print statements.

I tend to use print statements because it’s lazy and easy, adding logging needs some boiler plate code, hey we have yasnippets (emacs) and ultisnips (vim) and other templating tools, so why give up logging for plain print statements!?