RetroSearch Browse

Fri Jan 25 15:54:21 CET 2013 · https://mail.python.org/pipermail/python-dev/2013-January/123693.html

2013/1/25 Nick Coghlan <ncoghlan at gmail.com>:
> I just realised I could be converted to a +0 if the runtime time
> switch could only be used to set the global default as "cloexec=True"
> and couldn't be used to switch it back again (for testing purposes, if
> you only want to switch it on temporarily, use a subprocess). (...)

Oh, I like this idea. It does simplify many things :-)

(And I agree that subprocess can be used to run a test which requires
cloexec to be True by default.)

--

I tried to be future-proof. If we decide to enable close-on-exec flag
globally by default, how do you disable the flag globally? We may add
an inverse command line option and another environment variable (ex:
PYTHONNOCLOEXEC), but what about sys.setdefaultcloexec()?

In a previous version, my implementation expected an argument for
PYTHONCLOEXEC: PYTHONCLOEXEC=0 or PYTHONCLOEXEC=1. I realized that
it's not how other options (like PYTHONDONTWRITEBYTECODE) are
designed.

But do we really want to enable close-on-exec in the future? Charles
François has really good arguments against such choice :-) It's maybe
better to consider that the default at startup will always be False.
So we should only provide different ways to set the default to True.

Victor

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

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

Choose the default value of the new cloexec parameter