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

Gregory P. Smith greg at krypto.org
Sun Dec 5 20:08:43 CET 2010

On Sun, Dec 5, 2010 at 4:45 AM, Tres Seaver <tseaver at palladion.com> wrote:

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

On 12/04/2010 03:13 PM, Gregory P. Smith wrote: > > 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 'closefds' 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. Sleeping on the issue some more and pondering it...

Is there any good reason not to just make the close_fds default change in 3.2 today? No warning (since they're never seen by most people anyways). Document it in Misc/NEWS and whatsnew.rst.

The most common use case is likely the simpler one where close_fds is not specified because the caller doesn't care, not because they are relying on the default being False.

Another reason why I think changing it today is okay: This is Python 3.x. It has not yet seen wide adoption. It isn't likely to see wide adoption until 3.2. People migrating code to 3.2 are more likely to be migrating from 2.x than from 3.1. 2to3 can have a fixer added to specify close_fds=False on subprocess calls.

Consider this option B-prime.

-gps -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20101205/a8204afa/attachment.html>

More information about the Python-Dev mailing list