On Fri, Aug 23, 2013 at 1:30 PM, Charles-François Natali <cf.nat...@gmail.com> wrote: >> About your example: I'm not sure that it is reliable/portable. I sa >> daemon libraries closing *all* file descriptors and then expecting new >> file descriptors to become 0, 1 and 2. Your example is different >> because w is still open. On Windows, I have seen cases with only fd 0, >> 1, 2 open, and the next open() call gives the fd 10 or 13... > > Well, my example uses fork(), so obviously doesn't apply to Windows. > It's perfectly safe on Unix.
But relying on this in UNIX has also been discouraged ever since the dup2() system call was introduced. (I can't easily find a reference about its history but IIRC it is probably as old as UNIX v7 or otherwise BSD 4.x.) >> I'm optimistic and I expect that most Python applications and >> libraries already use the subprocess module. The subprocess module >> closes all file descriptors (except 0, 1, 2) since Python 3.2. >> Developers relying on the FD inheritance and using the subprocess with >> Python 3.2 or later already had to use the pass_fds parameter. > > As long as the PEP makes it clear that this breaks backward > compatibility, that's fine. IMO the risk of breakage outweights the > modicum benefit. I know this will break code. But it is for the good of mankind. (I will now review the full PEP, finally.) -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
