In python, why use logging instead of print?

Question

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.

Antiknock

For big projects logging is always a "best practice" because you can easily turn it on or off, and get more or less information. print offers neither of these advantages. – Queer

See i.e. blog.tplus1.com/index.php/2007/09/28/… – Anachronistic

I don't think there's ever a best use case for print. – Quail

The python logging documentation says the best use case for print is to display help messages for the user in a command line application. – Thurman

Reading all these answers, I want to ask the reverse question: is there ever a reason to not use logging? – Fillagree

I'd say print is also useful for writing to text files (e.g. print("text", file=f)), when you prefer its way of formatting over how f.write("text") does formatting. I think it depends on what exactly you're writing, though. – Spermatozoid

@Fillagree yes, you do not need any logging when you write code which never fails, never throws any exceptions and never crashes; you do not need to know about any errors or failures because they are unacceptable right from the start – Barthold

"I don't think there's ever a best use case for print" Sure there is - when you're too lazy to import logging! Only semi-joking - when writing a small script, or attempting to print-debug, there's really no reason to reach for logging when print is right there. – Tatiania

"You can easily turn it on or off" is the main advantage? I can also comment out my print statement with a # character. No? – Entertaining

Commenting out print in a giant code-base would be painful in every little corner in which it is sneaked in. Commenting out print is never really a 'switch'. You do need to hunt those statements down. – Splenetic

Answer 1

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 they want to propogate logging messages from your tool or not.

Rectilinear

Very well said. I will sometimes use print when debugging a throwaway script that I intend to run exactly once, but any code that will ever been seen by other human eyes or that is meant to last more than one day gets logger. – Lubricate

1. I know exactly where the print statement is because I usually write it in the specific place that I want to debug. 2. Logging to files and sockets? I don't see why I would want to log to these places if I am just debugging my own code as I am coding. 3. You can differenciate based on severity. Well, when I use print, it is usually one specific bug I am interested in. In summary, for debugging my own code print is enough for me. I will use the debugger every once in a while but using logging seems unnecessary when I code. – Entertaining

I have to agree with the @Entertaining – Hoick

print can be configured to output to files and the standard streams. – Undersigned

Answer 2

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.

Ottoman

Definitely +1 for sending output to files. Parsing a logfile in the post-mortem is much better than having to make it break again in an open console window to find the error. Basically, a logger is ideal for any time you need to debug the script after it has failed rather than while it is failing. It's also ideal for any time you have to debug a complex problem that requires you to analyze the program output. Basically, any time you're dealing with errors more complex that syntax errors, a logger will probably simplify that for you. – Abele

Answer 3

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.

Quail

Most of my debugging is because of my own inexperience. Once I realize what I'm doing wrong, I want to delete the print statements, rather than leave the embarrassing testimony to how much debugging I had to do. Would you still recommend using logging for those cases? – Clerkly

Answer 4

In brief, the advantages of using logging libraries do outweigh print as below reasons:

• Control what’s emitted
• Define what types of information you want to include in your logs
• Configure how it looks when it’s emitted
• Most importantly, set the destination for your logs

---

In detail, segmenting log events by severity level is a good way to sift through which log messages may be most relevant at a given time. A log event’s severity level also gives you an indication of how worried you should be when you see a particular message. For instance, dividing logging type to debug, info, warning, critical, and error. Timing can be everything when you’re trying to understand what went wrong with an application. You want to know the answers to questions like:

• “Was this happening before or after my database connection died?”
• “Exactly when did that request come in?”

Furthermore, it is easy to see where a log has occurred through line number and filename or method name even in which thread.

---

Here's a functional logging library for Python named loguru.

Medlar

Answer 5

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.

Ranket

Answer 6

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!?

Chalybite

Answer 7

I would add to all other mentionned advantages that the print function in standard configuration is buffered. The flush may occure only at the end of the current block (the one where the print is). This is true for any program launched in a non interactive shell (codebuild, gitlab-ci for instance) or whose output is redirected.

If for any reason the program is killed (kill -9, hard reset of the computer, …), you may be missing some line of logs if you used print for the same.

However, the logging library will ensure to flush the logs printed to stderr and stdout immediately at any call.

Phocaea

"The flush may occure only at function return." Which function? print()? No, output buffering can delay output even longer. "If for any reason the program is killed (kill -9, hard reset of the computer, …)," In that case, all bets are off anyways. Nothing a logging library can do about it. – Ember

I should have been a little more precise.  In non interactive shell (big part of the executions), print is block buffered and then the print are buffered until the end of the current block. The logging module ensures the flush at the end of each call. So yes, in case of kill -9 or hard reset, we could still find all lines in the output where some could be missing if print had been used. – Phocaea

What is your definition of 'block'? – Ember

Let say you have ` def demo(): print("a") time.sleep("120") print("b") ` in a non interactive shell, you will see "a" appear at the same time as "b", directly at the end of the 120 seconds count. – Phocaea

Or even later. The duration of a function call has nothing to do with how long stuff is buffered. – Ember

Anyway, the print will appear only when demo returns and we can reasonably expect in the given example it will be around 120 seconds. – Phocaea

Can us print("hello world", flush=True) – Complaisant

The flush argument is a valid solution starting from python 3.3. However, the built-in logging module is the best solution for the logging use case. – Phocaea

Answer 8

For my case: When I moved my application in server, I can't see print output, then I added logging and now I can see output in terminal and a logging file.

Logs Loading in Terminal:

cd /base_path/logs/

tail -f console.log

Unsegregated

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Hildagarde