When printing to a closed stdout file descriptor, the print statement only raises an IOError at character 8192. 

The expected behaviour is that IOError gets raised immediately (i.e. on the first character). Compare this behaviour to writing to a closed sys.stderr.

To reproduce (using bash):

<pre>
# python -V
Python 2.6.4

# python -c 'print "x" * 8191' 1>&- ; echo $?
close failed in file object destructor:
Error in sys.excepthook:

Original exception was:
0

# python -c 'print "x" * 8192' 1>&- ; echo $?
Traceback (most recent call last):
  File "<string>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor
1
</pre>

This is not a bug. The output stream gets buffered, and that it is closed is only detected when a flush is attempted. Use the -u option if you want unbuffered stdout.

It is, however, a bug that Python 2.6 apparently fails to flush the output at all; Python 2.5 did that correctly.

This is not quite correct:

The following 2 lines fail as expected (unbuffered):

<pre>
python -u -c 'import sys; print >> sys.stdout, "x"' 1>&- ; echo $?
python -u -c 'import sys; print >> sys.stderr, "x"' 2>&- ; echo $?
</pre>

whereas in the following example, the first command succeeds and the second one fails:

<pre>
python -c 'import sys; print >> sys.stdout, "x"' 1>&- ; echo $?
python -c 'import sys; print >> sys.stderr, "x"' 2>&- ; echo $?
</pre>

This is counter-intuitive and somewhat contradicts the documentation, as stderr always seems to be unbuffered (irrespective of the -u option). IMHO, they should either both fail or both succeed.

They seem to behave the same in 2.5 & 2.6, however in 3.1, they all die with a SIGABRT, which I guess could be questioned as well. IMHO, they should just throw an exception like in 2.6.

Is there any interest in following this up as 2.6 is out of support?

It's still a problem in Python 2.7:

python -c 'import sys; print >> sys.stdout, "x"' 1>&- ; echo $?
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
0

But feel free to close as "won't fix", as this seems to be an edge case which might not be worth fixing.

A similar problem seems to appear in Python 3.5

./python -c 'import sys; print("x", file=sys.stdout)' 1>&- ; echo $? 
0

./python -c 'import sys; print("x", file=sys.stderr)' 2>&- ; echo $?
x
0

but again, this does seem to be a very specific corner case.

I have no interest to work on this.

Reproduced on 3.11:

cpython % ./python.exe -c 'import sys; print("x", file=sys.stdout)' 1>&- ; echo $? 
0
cpython % ./python.exe -c 'import sys; print("x", file=sys.stderr)' 2>&- ; echo $?
x
0