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

Charles-François Natali cf.natali at gmail.com
Tue Jan 29 07:13:39 CET 2013


> Library code should not be relying on globals settings that can change.
> Library code should be explicit in its calls so that the current value of a
> global setting is irrelevant.

That's one of the problems I've raised with this global flag since the
beginning: it's useless for libraries, including the stdlib (and, as a
reminder, this PEP started out of a a bug report against socket
inheritance in socketserver).

And once again, it's an hidden global variable, so you won't be able
any more to tell what this code does:
"""
r, w = os.pipe()
if os.fork() == 0:
    os.close(w)
    os.execve(['myprog'])
"""

Furthermore, if the above code is part of a library, and relies upon
'r' FD inheritance, it will break if the user sets the global cloexec
flag. And the fact that a library relies upon FD inheritance is an
implementation detail, the users shouldn't have to wonder whether
enabling a global flag (in their code, not in a library) will break a
given library: the only alternative for such code to continue working
would be to pass cloexec=True explicitly to os.pipe()...

The global socket.settimeout() is IMO a bad idea, and shouldn't be emulated.

So I'm definitely -1 against any form of tunable value (be it a
sys.setdefaultcloexec(), an environment variable or command-line
flag), and still against changing the default value.

But I promise that's the last time I'm bringing those arguments up,
and I perfectly admit that some people want it as much as I don't want
it :-)

cf


More information about the Python-Dev mailing list