On Sun, 27 Jan 2013 12:23:15 +0100 Victor Stinner <victor.stin...@gmail.com> wrote: > 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).
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. Regards Antoine. _______________________________________________ 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
