2013/1/27 Guido van Rossum <gu...@python.org>: > I had missed this detail. I agree that it should be exposed in the > interpreter. To my mind it is more like PYTHONPATH (which corresponds > roughly to sys.path manipulations) than like -R (which changes > something that should never be changed again, otherwise the sanity of > the interpreter be at risk). It would seem hard to unittest the > feature if it cannot be changed from within. But I can also think of > other use cases for changing it from within (e.g. a script that > decides on how to set it using a computation based on its arguments).
sys.path is usually only used to add a new path, not to remove path from other libraries. I'm not sure that it's the best example to compare it to sys.setdefaultcloexec(). If sys.setdefaultcloexec() accepts an argument (so allow sys.setdefaultcloexec(False)), problems happen when two libraries, or an application and a library, disagree. Depending how/when the library is loaded, the flag may be True or False. I prefer to have a simple sys.setdefaultcloexec() which always set the flag to True. It's also simpler to explain how the default value is computed (it's less surprising). -- Unit tests can workaround the limitation using subprocesses. My implementation doesn't use sys.setdefaultcloexec() anymore, it just ensures that functions respect the current default value. I ran tests manually to test both default values (True and False). Tests may be improved later to test both defalut values using subprocess. 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
