With a 2.6 or 2.7 debug build:
    python_d -c "import os; os.fdopen(2)"

Displays the famous Debug Assertion Failure:
    ...
    Expression: (_osfile(fh) & FOPEN)
    ...

The error occurs when closing pyhon, in call_ll_exitfuncs() there is a
call to fflush(stderr)

Well, the short answer is don´t do that!

Do os.fdopen(os.fdup(2))
You are stealing the fd 2 away from stderr, then closing it, and stderr 
now holds a defunct file descriptor.

Sure. But we tried hard to remove all these assertion failures, so that 
python never shows a popup dialog.

Yes.  We have tried to accomodate the most reckless use of file 
descriptors.
I'm not sure how to proceed here though, since the builtin streams are 
beyond our control.

I think you would have the same effect if you called os.close(2).

Perhaps the only really good solution is to allow for disabling the fd 
checks after all, but to make it optional, somehow.  Ideally something 
that python.exe sets up, it being the prime motivator....

Really, this fd checking in mscrt is becoming really annoying.  I'm 
inclined to start lobbying MS to remove at least that part of the 
runtime checks by default.  Not that it will do us any good.

Or, perhaps, we should just document the caveats with using file 
descriptors directly in python.  That one has to be careful with their 
use, for example, to not steal them from streams that may be using 
them, not closing them when someone else is, and so on.  Use at your 
own risk.  After all, there are numerous ways to crash python through 
reckless use of code, e.g. by using ctypes.

I thought there was a _PyVerify_Fd() just for that, why couldn't it be
used here too?
(not that I think sparkling _PyVerify_Fd() everywhere in our code base
is reasonable and maintainable, but I didn't make that choice :-))