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

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