RetroSearch Browse

Sat Jan 12 21:29:18 CET 2013 · https://mail.python.org/pipermail/python-dev/2013-January/123608.html

2013/1/11 Ben Leslie <benno at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-January/123608.html below:

[Python-Dev] fork or exec?