On Sun, 27 Jan 2013 12:23:15 +0100 Victor Stinner <victor.stinner at gmail.com> wrote: > 2013/1/27 Guido van Rossum <guido at 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4