On Sun, Jan 27, 2013 at 9:29 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > I don't think such limitations are very useful in practice. Users > calling sys.setdefaultexec() will have to be sufficiently knowledgeable > to understand the implications, anyway.
I've yet to hear a use case for being able to turn it off globally if the application developer has indicated they want it on. A global flag that can be turned off programmatically is worse than no global flag at all. If we're never going to migrate to cloexec-on-by-default, then there simply shouldn't be a global flag - the option should just default to False. If we're going to migrate to cloexec-on-by-default some day, then the global flag should purely be a transition strategy to allow people to try out that future behaviour and adjust their application appropriately (by clearing the flag on descriptors that really need to be inherited). The typical default that should be assumed by library code will still be cloexec-off-by-default. A completely flexible global flag is just a plain bad idea for all the reasons Charles-François gave. Regards, 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
