2013/1/11 Ben Leslie <be...@benno.id.au>: > Python is not UNIX, but I think if you are directly using the POSIX > interfaces they should > work (more or less) the same way the would if you were writing a C program. > (Some of us > still use Python to prototype things that will later be converted to C!).
I completed the PEP to list advantages and drawbacks of the different alternatives. I moved the PEP to the PEP repository because I now consider it complete enough (for a first draft!): http://www.python.org/dev/peps/pep-0433/ I see 3 major alternatives: (a) add cloexec=False argument to some functions http://www.python.org/dev/peps/pep-0433/#proposition Drawbacks: http://www.python.org/dev/peps/pep-0433/#scope (b) always set close-on-exec flag and add cloexec=True argument to some functions (to be able to disable it) http://www.python.org/dev/peps/pep-0433/#always-set-close-on-exec-flag (c) add cloexec argument to some functions and a sys.setdefaultcloexec() function to change the default value of cloexec (will be False at startup) http://www.python.org/dev/peps/pep-0433/#add-a-function-to-set-close-on-exec-flag-by-default If you care about backward compatibility, (a) is the safest option. If you care about bugs and security, (b) is the best option. For example, (a) does not fix os.urandom(). (c) tries to be a compromise, but has its own drawbacks. Victor _______________________________________________ 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
