[Python-Dev] PEP 446 (make FD non inheritable) ready for a final review

[Guido van Rossum]

On Fri, Aug 23, 2013 at 1:30 PM, Charles-François Natali
<cf.natali at 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)