[Python-Dev] PEP 446: Open issues/questions

[Victor Stinner]

2013/7/28 Charles-François Natali <cf.natali at gmail.com>:
> 2013/7/28 Antoine Pitrou <solipsis at pitrou.net>:
>>> (C) Should we handle standard streams (0: stdin, 1: stdout, 2: stderr)
>>> differently? For example, os.dup2(fd, 0) should make the file
>>> descriptor 0 (stdin) inheritable or non-inheritable? On Windows,
>>> os.set_inheritable(fd, False) fails (error 87, invalid argument) on
>>> standard streams (0, 1, 2) and copies of the standard streams (created
>>> by os.dup()).
>>
>> I have been advocating for that, but I now realize that special-casing
>> these three descriptors in a myriad of fd-creating functions isn't very
>> attractive.
>> (if a standard stream fd has been closed, any fd-creating function can
>> re-create that fd: including socket.socket(), etc.)

>> So perhaps only the *original* standard streams should be left
>> inheritable?

I plan to only change functions *creating* (and replacing) new file
descriptors. Existing file descriptors (like 0, 1, 2) are unchanged.

> Having stdin/stdout/stderr cloexec (e.g. after a dup() to redirect to
> a log file, a socket...) will likely break a lot of code, e.g. code
> using os.system(), or code calling exec manually (and I'm sure there's
> a bunch of it).

I propose to add just one special case os.dup2(fd, fd2): if fd2 < 3,
fd2 is set to inheritable (otherwise, fd2 is set to non-inheritable).
os.dup2() is commonly used to replace stdin, stdout and stderr between
fork and exec. The http.server (cgi server) and pty modules use dup2()
for example

http://hg.python.org/features/pep-446/rev/f8a52518be4c

Victor