(original) (raw)
On Sat, Dec 4, 2010 at 3:45 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sat, �4 Dec 2010 10:10:44 +0100 (CET)That doesn't seem to be a good idea under Windows, is it?
gregory.p.smith <python-checkins@python.org> wrote:
> Author: gregory.p.smith
> Date: Sat Dec �4 10:10:44 2010
> New Revision: 87010
>
> Log:
> issue7213 + issue2320: Cause a DeprecationWarning if the close\_fds argument is
> not passed to subprocess.Popen as the default value will be changing in a
> future Python to the safer and more often desired value of True.
(�Note that on Windows, you cannot set \*close\_fds\* to true and
also redirect the standard handles by setting \*stdin\*, \*stdout\* or\*stderr\*.�)
Regardless of what platform you are on I think the warning makes sense, it was just worded too strongly. �It is asking people to be explicit with close\_fds. �Explicitly setting close\_fds=False when that is desired is good.
I modified the docs and warning message to just say that the default close\_fds behavior will change in the future without specifying exactly what it will be. �It could make sense for the default to be a soft-True on windows that changes behavior if any of the std handles are set if that matches what users expect and find easiest. �We may want to reconsider its entire future in the face of the new pass\_fds parameter, etc. �Those are 3.3 decisions.
-gps