homepage

On 14/03/2013 1:00pm, Martin v. Löwis wrote:
> That's why I was asking for an actual patch. The proposed change may
> well not be implementable. If os.open continues to create CRT handles,
> a way needs to be found to get a CRT handle that as the
> FILE_SHARE_DELETE bit set.
The patch *does* create CRT fds from win32 handles by using 
msvcrt.open_osfhandle().
One other issue is that I do not know of a way to determine the current 
umask without temporarily changing it, causing a thread-race.
In the end I am not sure it is worth the hassle. (But maybe it would be 
a good idea to add test.support.open() using FILE_SHARE_DELETE and 
test.support.unlink() to make the testsuite more resilient to 
"Permission Denied" errors.)
> An alternative approach could be that os.open stops creating CRT
> handles, and directly uses OS handles. The problem with that is that
> stdin/stdout/stderr would stop being 0/1/2, which is not acceptable.
> An alternative solution to that could be that we introduce a notion
> of "python io handles", parallel, but indepedendent from CRT handles.
> And so on.
http://bugs.python.org/issue12939 has C implementations of _io.WinFileIO 
and _io.openhandle() which are equivalents for _io.FileIO and os.open() 
which use "native" Windows handles.