> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4