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

[Gregory P. Smith]

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 close_fds 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 close_fds=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 close_fds behavior.  we're stuck with it for life.
> >
> > D) Deprecate close_fds so that it becomes a legacy no-op.  the new
> pass_fds
> > flag could evolve into this.  this will break existing code that depends
> on
> > close_fds one way or another.
> >
> >
> > I'm in 100% agreement that forcing people to pass close_fds 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.
>
>
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>