2013/8/26 Guido van Rossum <gu...@python.org>: > I have reviewed the PEP and I think it is good. Thank you so much for > pushing this topic and for your very thorough review of all the feedback, > related issues and so on. It is an exemplary PEP!
Thanks :-) I updated the PEP: http://hg.python.org/peps/rev/edd8250f6893 > I've made a bunch of small edits (mostly to improve grammar slightly, hope > you don't mind) and committed these to the repo. Thanks, I'm not a native english speaker, so not problem for such edit. > https://codereview.appspot.com/13240043/diff/3001/pep-0446.txt#newcode437 > pep-0446.txt:437: condition. > As C-F Natali pointed out, this is not actually a problem, because after > fork() > only the main thread survives. Maybe just delete this paragraph? Ok, I didn't know that only one thread survives to fork(). (I read Charles' email, but I forgot to update the PEP.) I simply deleted the paragraph. > https://codereview.appspot.com/13240043/diff/3001/pep-0446.txt#newcode450 > pep-0446.txt:450: parameter is a non-empty list of file descriptors. > Well, it could pass closefrom() the max of the given list and manually close > the > rest. This would be useful if the system max is large but none of the FDs > given > in the list is. (This would be more complex code but it would address the > issue > for most programs.) This was related to the multi-thread issue, which does not exist, so I also removed this paragraph. Using closefrom() to optimize subprocess is unrelated to this PEP. (And yes, the maximum file descriptor can be huge!) > https://codereview.appspot.com/13240043/diff/3001/pep-0446.txt#newcode538 > pep-0446.txt:538: descriptors). > I would say it should not be changed because the default is still better. > :-) (The PEP does not propose to change the default value.) Under Linux, recent versions of the glibc uses non-inheritable FD for internal files. Slowly, more and more libraries and programs will do the same. This PEP is a step in this direction ;-) 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
