Guido van Rossum wrote:
> I still don't understand. Why do you need to treat a closed fd
> different from an invalid fd. In both cases you can't use it and you
> shouldn't close it.

I don't want to treat the fd differently. I want to return a sensible
error message that is different from "file closed" when the fd is invalid.

> I'd suggest that, on Windows, sys.std{in,out.err} should be set to
> None instead of a file object when their file descriptor is invalid.
> That way print and write requests will fail immediately instead of
> nondeterministically. With an invalid file that only blows upwhen
> trying to flush you may be able to write a small traceback but it will
> still blow up if the traceback is big.

But wouldn't that cause a fatal error when sys.stderr is missing and
Python can't write the traceback to a file like object?

*testing*

No, it works:

object  : Exception('msg',)
type    : Exception
refcount: 4
address : 0x839d274
lost sys.stderr

I've an alternative solution based on Amaurgy's idea. Python could set
replacements for stdin, stdout and stderr before it sets up the
preliminary stderr:

#ifdef MS_WINDOWS
	/* The standard streams of Windows GUI apps aren't connected. */
	if (fileno(stdin) < 0) {
		if (freopen("NUL", "rb", stdin) == NULL)
			Py_FatalError("Py_Initialize: failed to replace stdin");
	}
	if (fileno(stdout) < 0) {
		if (freopen("NUL", "wb", stdout) == NULL)
			Py_FatalError("Py_Initialize: failed to replace stdout");
	}
	if (fileno(stderr) < 0) {
		if (freopen("NUL", "wb", stderr) == NULL)
			Py_FatalError("Py_Initialize: failed to replace stderr");
	}
#endif