On Fri, Jan 25, 2013 at 6:56 PM, Charles-François Natali <cf.nat...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
