[Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

[Nick Coghlan]

On Fri, Jan 25, 2013 at 6:56 PM, Charles-François Natali
<cf.natali at gmail.com> wrote:
> Hello,
>
>> I tried to list in the PEP 433 advantages and drawbacks of each option.
>>
>> If I recorded correctly opinions, the different options have the
>> following supporters:
>>
>>  a) cloexec=False by default
>>  b) cloexec=True by default: Charles-François Natali
>>  c) configurable default value: Antoine Pitrou, Nick Coghlan, Guido van Rossum
>
> You can actually count me in the cloexec=False camp, and against the
> idea of a configurable default value. Here's why:
>
> Why cloexec shouldn't be set by default:
> - While it's really tempting to fix one of Unix historical worst
> decisions, I don't think we can set file descriptors cloexec by
> default: this would break some applications (I don't think there would
> be too many of them, but still), but most notably, this would break
> POSIX semantics. If Python didn't expose POSIX syscalls and file
> descriptors, but only high-level file streams/sockets/etc, then we
> could probably go ahead, but now it's too late. Someone said earlier
> on python-dev that many people use Python for prototyping, and indeed,
> when using POSIX API, you expect POSIX semantics.
>
> Why the default value shouldn't be tunable:
> - I think it's useless: if the default cloexec behavior can be altered
> (either by a command-line flag, an environment variable or a sys
> module function), then libraries cannot rely on it and have to make
> file descriptors cloexec on an individual basis, since the default
> flag can be disabled. So it would basically be useless for the Python
> standard library, and any third-party library. So the only use case is
> for application writers that use raw exec() (since subprocess already
> closes file descriptors > 3, and AFAICT we don't expose a way to
> create processes "manually" on Windows), but there I think they fall
> into two categories: those who are aware of the problem of file
> descriptor inheritance, and who therefore set their FDs cloexec
> manually, and those who are not familiar with this issue, and who'll
> never look up a sys.setdefaultcloexec() tunable (and if they do, they
> might think: "Hey, if that's so nice, why isn't it on by default?
> Wait, it might break applications? I'll just leave the default
> then.").

It's a configurable setting in the same way that -Q makes the
behaviour of "/" configurable in Python 2 (so your hypothetical
example isn't hypothetical at all - it's a description the -Q option),
and -R makes random hashing configurable in 2.7 and 3.2: it means we
can change the default behaviour in a future version (perhaps Python
4) while allowing people to easily check if their code operates
correctly in that state in the current version.

I think the default behaviour needs to be configurable from the
environment and the command line, but I don't believe it should be
configurable from within the interpreter.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia