<br><br><div class="gmail_quote">On Sat, Dec 4, 2010 at 11:28 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 4 December 2010 18:14, Gregory P. Smith <<a href="mailto:greg@krypto.org">greg@krypto.org</a>> wrote:<br>
><br>
><br>
> On Sat, Dec 4, 2010 at 3:45 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
>><br>
>> On Sat, 4 Dec 2010 10:10:44 +0100 (CET)<br>
>> gregory.p.smith <<a href="mailto:python-checkins@python.org">python-checkins@python.org</a>> wrote:<br>
>> > Author: gregory.p.smith<br>
>> > Date: Sat Dec 4 10:10:44 2010<br>
>> > New Revision: 87010<br>
>> ><br>
>> > Log:<br>
>> > issue7213 + issue2320: Cause a DeprecationWarning if the close_fds<br>
>> > argument is<br>
>> > not passed to subprocess.Popen as the default value will be changing in<br>
>> > a<br>
>> > future Python to the safer and more often desired value of True.<br>
>><br>
>> That doesn't seem to be a good idea under Windows, is it?<br>
>><br>
>> (“Note that on Windows, you cannot set *close_fds* to true and<br>
>> also redirect the standard handles by setting *stdin*, *stdout* or<br>
>> *stderr*.”)<br>
><br>
> Regardless of what platform you are on I think the warning makes sense, it<br>
> was just worded too strongly. It is asking people to be explicit with<br>
> close_fds. Explicitly setting close_fds=False when that is desired is good.<br>
> I modified the docs and warning message to just say that the default<br>
> close_fds behavior will change in the future without specifying exactly what<br>
> it will be. It could make sense for the default to be a soft-True on<br>
> windows that changes behavior if any of the std handles are set if that<br>
> matches what users expect and find easiest. We may want to reconsider its<br>
> entire future in the face of the new pass_fds parameter, etc. Those are 3.3<br>
> decisions.<br>
<br>
</div></div>This sounds like omitting the close_fds parameter is now considered<br>
ill-advised, if not outright wrong. That's silly - I certainly never<br>
specify close_fds, expecting the module to do the correct thing if I<br>
don't know/care enough to say. I use Popen as a convenience function,<br>
so ignoring low-level details is the whole point in my opinion (and<br>
close_fds *is* a low-level detail for what I do, on Windows).<br>
<br>
At the very least, the whole of the section "Replacing Older Functions<br>
with the subprocess Module" (with a couple of small exceptions) is in<br>
need of updating, as it is recommending bad practice (not specifying<br>
close_fds) at the moment...<br>
<br>
OK, I'm exaggerating a touch here. But can someone point me at the<br>
discussion of this change? Or if there hasn't been one, can we have<br>
one (i.e., to start the ball rolling, can someone justify the change,<br>
please).<br>
<font color="#888888"><br>
Paul.<br>
</font></blockquote></div><br><div>Making the change was intended to force the discussion. I'm glad that worked. :)</div><div><br></div><div>I don't like the thought of requiring people to specify close_fds either but the default is a bad one (see <a href="http://bugs.python.org/">http://bugs.python.org/</a><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">issue7213 and </span><a href="http://bugs.python.org/">http://bugs.python.org/</a><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">issue2320) so we should change it.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">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.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Options that seem worthy of debate:</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">A) The DeprecationWarning that exists in py3k as of today.</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">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.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">C) Never change close_fds behavior. we're stuck with it for life.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">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.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">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?).</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Option B seems the most friendly to me.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Option D is always on the table but I haven't planned out what a future without it should look like. I prefer requiring people who need open file descriptors to pass them in; a semaphore for "all fds" could be created and pass_fds=ALL becomes the new "close_fds=False" (I think one of the bugs suggests this).</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">-gps</span></div>
<meta charset="utf-8"><meta charset="utf-8">