It's unlikely but still possible that fd is a directory. For example, say the directory was opened with CreateFile (via ctypes, PyWin32, etc) and the file descriptor was opened with msvcrt.open_osfhandle. Granted the fstat check has never worked on Windows, but we could actually make it work rather than skip it:

BY_HANDLE_FILE_INFORMATION info;
HANDLE hfile = (HANDLE)_get_osfhandle(fd);
if (GetFileType(hfile) == FILE_TYPE_DISK && 
    GetFileInformationByHandle(hfile, &info) && 
    info.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
    ...

Yes, I considered that fd can refer to a directory, but I wasn't sure whether we should bother to fix dircheck in 2.7. I mentioned in the bug report that if we do want to fix dircheck, we may use 3.x approach, which is the same that you propose (in _Py_fstat_noraise). If I get more feedback suggesting to fix dircheck, I'll update the patch. Thank you!

This suggestion was only for this inline check in os.fdopen. I don't think dircheck in fileobject.c should even be called on Windows.

We can't open a directory via [_w]fopen in Windows, so how about just skipping the dircheck calls in fill_file_fields and open_the_file?

Yes, it's possible if we don't want to make dircheck work on Windows (I changed dircheck instead of its callers just because it makes a smaller patch). It also makes sense to put dircheck under #ifndef MS_WINDOWS in this case.

If dircheck is to be fixed instead, the call in fill_file_fields can't be removed because fill_file_fields is called by PyFile_FromFile which accepts FILE * of potentially unknown origin (not necessarily from fopen).

I may update the patch once there is a decision about fixing dircheck for Windows.

For PyFile_FromFile I'm not really concerned about a C extension doing something silly. I don't think the check is necessary. It never worked, and no one ever complained that it didn't work, so my vote is to retain the status quo by either skipping the dircheck call or making it a no-op.

Now I see your points here and above, but is there any reason to make os.fdopen behave differently compared to PyFile_FromFile (and, as a result, stdin check)? Directory checks never worked in both of them.

My reasoning was that we can end up with an fd for a directory using PyWin32 and msvcrt.open_osfhandle. OTOH, C FILE streams are definitely outside of the domain of Python. If we consider code that directly calls CreateFile (via PyWin32 or ctypes) to be on the periphery, then the check in os.fdopen doesn't need to be fixed. It never worked, so the status quo is preserved by skipping it.

Thank you, I understand your reasoning. A nitpick: we can still abuse PyFile_FromFile without a third-party extension module since it's used to wrap std streams.

import ctypes, msvcrt, subprocess, sys
h = ctypes.windll.kernel32.CreateFileA(
  ".",
  0,
  0,
  0,
  3,          # OPEN_EXISTING
  0x02000000, # FILE_FLAG_BACKUP_SEMANTICS 
  0,
)
fd = msvcrt.open_osfhandle(h, 0)
subprocess.check_call([sys.executable, '-c', 'import sys; sys.stdout.write("OK")'],
                      stdout=fd)        

The above prints the following:

close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

Personally, I'd either fix both os.fdopen and PyFile_FromFile or preserve the status quo, and I'm more inclined to the latter.