printing to a file in Python: redirect vs print's file argument vs write

Question

I have a bunch of print calls that I need to write to a file instead of stdout. (I don't need stdout at all.)

I am considering three approaches. Are there any advantages (including performance) to any one of them?

Full redirect, which I saw here:

import sys

saveout = sys.stdout
fsock = open('out.log', 'w')
sys.stdout = fsock

print(x)
# and many more print calls

# later if I ever need it:
# sys.stdout = saveout
# fsock.close()

Redirect in each print statement:

fsock = open('out.log', 'w')
print(x, file = fsock)
# and many more print calls

Write function:

fsock = open('out.log', 'w')
fsock.write(str(x))
# and many more write calls

Answer 1

I would not expect any durable performance differences among these approaches.

The advantage of the first approach is that any reasonably well-behaved code which you rely upon (modules you import) will automatically pick up your desired redirection.

The second approach has no advantage. It's only suitable for debugging or throwaway code ... and not even a good idea for that. You want your output decisions to be consolidated in a few well-defined places, not scattered across your code in every call to print(). In Python3 print() is a function rather than a statement. This allows you to re-define it, if you like. So you can def print(*args) if you want. You can also call __builtins__.print() if you need access to it, within the definition of your own custom print(), for example.

The third approach ... and by extension the principle that all of your output should be generated in specific functions and class methods that you define for that purpose ... is probably best.

You should keep your output and formatting separated from your core functionality as much as possible. By keeping them separate you allow your core to be re-used. (For example you might start with something that's intended to run from a text/shell console, and later need to provide a Web UI, a full-screen (curses) front end or a GUI for it. You may also build entirely different functionality around it ... in situations where the resulting data needs to be returned in its native form (as objects) rather than pulled in as text (output) and re-parsed into new objects.

For example I've had more than one occasional where something I wrote to perform some complex queries and data gathering from various sources and print a report ... say of the discrepancies ... later need to be adapted into a form which could spit out the data in some form (such as YAML/JSON) that could be fed into some other system (say, for reconciling one data source against another.

If, from the outset, you keep the main operations separate from the output and formatting then this sort of adaptation is relatively easy. Otherwise it entails quite a bit of refactoring (sometimes tantamount to a complete re-write).