Introduction

Python does not flush file output after every write() by default. It usually buffers data in memory and flushes it only at specific times such as when the buffer fills, when you explicitly call flush(), or when the file is closed. The exact behavior depends on how the file was opened and what buffering mode is in use.

What Flushing Actually Means

Flushing moves buffered data from Python's file object to the operating system. That is useful, but it is not the same as guaranteeing the bytes are physically committed to disk.

This distinction matters:

• 'file.flush() pushes Python's buffered data onward'
• 'os.fsync(file.fileno()) asks the OS to sync file contents to storage'

If your question is about visibility to another process, flush() may be enough. If your question is about crash-safe durability, you often need fsync() as well.

Default File Writes Are Buffered

A simple example:

with open("example.txt", "w") as f:
    f.write("hello")
    # data may still be buffered here

Python does not promise that "hello" reaches the file immediately after write(). The runtime may wait until:

• the buffer becomes full
• you call f.flush()
• the file is closed

That buffering is good for performance because frequent tiny writes are expensive.

When Python Flushes Automatically

In normal file I/O, the most important automatic flush points are:

1. when the file object is closed
2. when the buffer policy decides it is time
3. when line buffering is enabled and a newline is written

Closing is the most common one:

with open("example.txt", "w") as f:
    f.write("hello\n")
# file closes here, which flushes buffered output

The with block is the preferred pattern partly because it guarantees the close happens even if an exception occurs.

Manual Flushing with flush()

If you need the data written out sooner, call flush():

1with open("example.txt", "w") as f:
2    f.write("step 1\n")
3    f.flush()
4    print("flushed after step 1")

This is common for:

• progress logs
• long-running processes
• debugging output written to a file
• cooperating with another process that reads the file while it is being written

Without flush(), the other process may not see the latest content yet.

Line Buffering Is Not the General Default

A common misconception is that Python flushes a text file every time it sees \n. That is only true when line buffering is actually enabled.

You can request it explicitly in text mode:

with open("example.txt", "w", buffering=1) as f:
    f.write("line one\n")  # line-buffered flush behavior

Line buffering is common in interactive streams such as terminals, but ordinary file writes are usually block-buffered by default.

So the rule is not "newline always flushes." The real rule is "newline flushes when line buffering is in effect."

print(..., flush=True) Is a Convenience

If you use print() with a file handle, you can force a flush directly:

with open("log.txt", "w") as f:
    print("started", file=f, flush=True)

This is just a convenient wrapper around writing plus flushing.

It is especially useful for quick scripts where explicit write() and flush() calls would be noisy.

If You Need Crash-Safe Durability

flush() alone may not be enough for truly durable writes. For example:

1import os
2
3with open("critical.txt", "w") as f:
4    f.write("important data")
5    f.flush()
6    os.fsync(f.fileno())

This is the more conservative pattern when power loss or process crashes matter.

Even then, real storage systems have their own behavior, but flush() + fsync() is much stronger than flush() alone.

Choosing the Right Strategy

Use default buffering when:

• performance matters
• you do not need immediate visibility
• the file is written and then closed normally

Use flush() when:

• readers must see intermediate results
• logs should appear promptly
• the process may run for a long time

Use fsync() when:

• the data must survive crashes as reliably as possible
• you are writing checkpoints or critical state

Those are different needs, and confusing them leads to either unnecessary slowdown or weaker durability than you expected.

Common Pitfalls

The biggest mistake is assuming write() means "already on disk." Usually it only means "accepted into buffering somewhere."

Another issue is believing that every newline automatically flushes every text file. That only applies when line buffering is enabled.

Developers also often call flush() and assume the data is fully durable after a machine crash. For stronger guarantees, use os.fsync() after flushing.

Finally, do not over-flush for no reason. Excessive flushing can hurt performance significantly in write-heavy code.

Summary

• Python usually buffers file output instead of flushing after every write().
• Data is typically flushed on close, when the buffer policy triggers, or when you call flush() explicitly.
• Newlines only imply flushing when line buffering is enabled.
• 'flush() is not the same as syncing bytes safely to disk.'
• Use os.fsync() after flush() when durability matters more than performance.