[Python-Dev] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py (original) (raw)

Tres Seaver tseaver at palladion.com
Sun Dec 5 13:45:02 CET 2010

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 12/04/2010 03:13 PM, Gregory P. Smith wrote:

On Sat, Dec 4, 2010 at 11:28 AM, Paul Moore <p.f.moore at gmail.com> wrote:

On 4 December 2010 18:14, Gregory P. Smith <greg at krypto.org> wrote:

On Sat, Dec 4, 2010 at 3:45 AM, Antoine Pitrou <solipsis at pitrou.net> wrote: On Sat, 4 Dec 2010 10:10:44 +0100 (CET) gregory.p.smith <python-checkins at 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 closefds 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. That doesn't seem to be a good idea under Windows, is it? (“Note that on Windows, you cannot set closefds 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 closefds. Explicitly setting closefds=False when that is desired is good. I modified the docs and warning message to just say that the default closefds 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 passfds parameter, etc. Those are 3.3 decisions. This sounds like omitting the closefds parameter is now considered ill-advised, if not outright wrong. That's silly - I certainly never specify closefds, expecting the module to do the correct thing if I don't know/care enough to say. I use Popen as a convenience function, so ignoring low-level details is the whole point in my opinion (and closefds is a low-level detail for what I do, on Windows). At the very least, the whole of the section "Replacing Older Functions with the subprocess Module" (with a couple of small exceptions) is in need of updating, as it is recommending bad practice (not specifying closefds) at the moment... OK, I'm exaggerating a touch here. But can someone point me at the discussion of this change? Or if there hasn't been one, can we have one (i.e., to start the ball rolling, can someone justify the change, please). Paul. Making the change was intended to force the discussion. I'm glad that worked. :) I don't like the thought of requiring people to specify closefds either but the default is a bad one (see http://bugs.python.org/issue7213 and http://bugs.python.org/issue2320) so we should change it. The real question is how should we go about doing the change? This warning asking people to always specify closefds=True is heavy handed. Other places in the stdlib and docs no doubt still need to be updated to reflect it, etc. Options that seem worthy of debate: A) The DeprecationWarning that exists in py3k as of today. B) Remove the DeprecationWarning, simply document that people should be explicit about it if they care at all and that the default will change in 3.3. C) Never change closefds behavior. we're stuck with it for life. D) Deprecate closefds so that it becomes a legacy no-op. the new passfds flag could evolve into this. this will break existing code that depends on closefds one way or another. I'm in 100% agreement that forcing people to pass closefds in makes the API less friendly (granted, people already find it unfriendly but why make it worse?). Option B seems the most friendly to me.

+1 from me. People who don't care about the 'close_fds' behavior one way or the other shouldn't get a warning which only helps the tiny (I assert) minority who a) do care but b) don't pass the flag explicitly.

Tres.. - --

Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz7iU4ACgkQ+gerLs4ltQ4SJgCfePUImv5OSHzzZ4QJvzUz1oYJ LhAAoKRut3AfGkS23hghQx9pd3D0WF3p =y8hn -----END PGP SIGNATURE-----

More information about the Python-Dev mailing list