homepage

$ python3.0 -c 'print((1, 2, 3))' > /dev/full || echo error status
$
This command gives no indication whatsoever that anything has gone
wrong. Following this with strace demonstrates that the interpreter is
in fact ignoring these errors:
2589 write(1, "(1, 2, 3)\n"..., 10) = -1 ENOSPC (No space left on
device)
2589 rt_sigaction(SIGINT, {SIG_DFL}, {0x47aa49, [], SA_RESTORER,
0x7fd5aa9da080}, 8) = 0
2589 write(1, "(1, 2, 3)\n"..., 10) = -1 ENOSPC (No space left on
device)
2589 write(1, "(1, 2, 3)\n"..., 10) = -1 ENOSPC (No space left on
device)
2589 write(1, "(1, 2, 3)\n"..., 10) = -1 ENOSPC (No space left on
device)
2589 exit_group(0) = ?

Can anyone with a Linux box please check to see if this is still an issue.

Yes, py3k r82745 still shows the problem

Yes, it's an issue in py3k. Also, I prefer the behavior of 2.5, but
I'm not sure if that can be changed easily in 2.7.
$ python2.5 -c 'print((1, 2, 3))' > /dev/full
close failed: [Errno 28] No space left on device
$ python2.7 -c 'print((1, 2, 3))' > /dev/full
close failed in file object destructor:
Error in sys.excepthook:
Original exception was:
$ python3.2 -c 'print((1, 2, 3))' > /dev/full
$

The issue is that when close() calls flush(), errors are silently discarded. I'm sure a similar issue was already filed, but could not find it.

> The issue is that when close() calls flush(), errors are silently
> discarded
This has been fixed in 3.1 and 3.2:
$ ./python -c "with open('/dev/full', 'w') as f: print('a', file=f)"
Traceback (most recent call last):
 File "<string>", line 1, in <module>
IOError: [Errno 28] No space left on device
However, it seems sys.stdout has a different treatment:
$ ./python -c "print('a')" > /dev/full
$

It looks like the error is cleared in Python/pythonrun.c, line 321:
 if (fout != NULL && fout != Py_None) {
 tmp = PyObject_CallMethod(fout, "flush", "");
 if (tmp == NULL)
 PyErr_Clear();
 else
 Py_DECREF(tmp);
 }
Not sure why it isn't handled before that.

I agree that errors while flushing stdout shouldn't be silenced but instead reported (on stderr, obviously :-)). It is especially important when scripts are used for data processing.
I'd like to have Guido's opinion, though.

Closing as a duplicate of issue 5319.