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

[Nick Coghlan]

On Sat, Jan 26, 2013 at 12:54 AM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> But do we really want to enable close-on-exec in the future? Charles
> François has really good arguments against such choice :-)

While many of Python's APIs are heavily inspired by POSIX, it still
isn't POSIX. It isn't C either, especially in Python 3 (where C
truncating division must be written as "//" and our internal text
handling has made the migration to being fully Unicode based)

> It's maybe
> better to consider that the default at startup will always be False.
> So we should only provide different ways to set the default to True.

I think Charles François actually hit on a fairly good analogy by
comparing this transition to the integer division one. To implement
that:

1. In 2.x, the "-Q" option was introduced to allow the behaviour to be
switched globally, while ensuring it remained consistent for the life
of a given application
2. The "//" syntax was introduced to force the use of truncating
integer division
3. "float(n) / d" could be used to force floating point division

Significantly, code written using either option 2 or option 3 retains
exactly the same semantics in Python 3, even though the default
behaviour of "/" has now switched from truncating division to floating
point division. Note also that in Python 3, there is *no* mechanism to
request truncating division globally - if you want truncating
division, you have to explicitly request it every time.

So, if we agree that "cloexec-by-default" is a desirable goal, despite
the inconsistency with POSIX (just as changing integer division was
seen as desirable, despite the inconsistency with C), then a sensible
transition plan becomes:

1. Introduce a mechanism to switch the behaviour globally, while
ensuring it remains consistent for the life of a given application
2. Introduce the "cloexec=None/True/False" 3-valued parameter as
needed to allow people to choose between
default/definitely-cloexec/definitely-not-cloexec.
3. At some point in the future (perhaps in 3.5, perhaps in 4.0) switch
the default behaviour to cloexec=True and remove the ability to change
the behaviour globally.

The reason I'd be +0 on a "one-way switch", even at runtime, is that
you can just make it a no-op after that behaviour becomes the default.

Cheers,
Nick.

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