From 458823f410c9171372fda7705d11705bd035a6eb Mon Sep 17 00:00:00 2001 From: Victor Stinner Date: Tue, 27 Aug 2013 22:21:31 +0200 Subject: [PATCH] PEP 446: clarify impact on performances of the PEP It is not always possible to set close_fds to False, when this PEP makes it safe in some cases. --- pep-0446.txt | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/pep-0446.txt b/pep-0446.txt index ff5dac24e..c36b1543b 100644 --- a/pep-0446.txt +++ b/pep-0446.txt @@ -539,10 +539,14 @@ safe to use subprocess with the *close_fds* parameter set to ``False``. Not closing explicitly file descriptors is faster, especially on platform with a large maximum number of file descriptors. -The default value of the *close_fds* parameter is unchanged, because -third party modules, especially extensions implemented in C, may not -conform immediatly to the PEP 446 (still create inheritable file -descriptors). +The default value of the *close_fds* parameter of the ``subprocess`` +module is unchanged, file descriptors and handles are still closed +explicitly on UNIX. Third party modules, especially extensions +implemented in C, can still create inheritable file descriptors and +handles. But with this PEP, it becomes safe to set *close_fds* to +``False`` when all file descriptors and handles are created +non-inheritable, which is faster on UNIX when the maximum number of file +descriptors is large. Backward Compatibility