Message123743
Setting CLOEXEC on the pipes seems like a very good fix for this bug. I'm +1 on it, but I think it should be the default; instead, your proposed patch adds a new argument to the public API. Why do you think it's necessary to do so?
At the same time, we need a solution to handle close_fds, because the current status of the 3.2 with the DeprecationWarning (on 90% of subprocess uses in the world, if it ever gets backported to 2.7) and no way to fix it in a multi-platform way is really sad.
I don't think a new constant DISREGARD_FDS is necessary. I think we can just use "None" as intermediate default (just like the current 3.2 does), and later switch it to True. The only further required action is to make "True" always work on Windows and never error out (just make it do nothing if there are some redirections), which is an obviously good thing to do to increase portability of subprocess.
Otherwise, if this can't make 3.2, I think the DeprecationWarning should be reverted until we agree on a different solution. |
|
Date |
User |
Action |
Args |
2010-12-10 19:30:35 | Giovanni.Bajo | set | recipients:
+ Giovanni.Bajo, gregory.p.smith, paul.moore, milko.krachounov |
2010-12-10 19:30:35 | Giovanni.Bajo | set | messageid: <1292009435.61.0.811362413886.issue7213@psf.upfronthosting.co.za> |
2010-12-10 19:30:34 | Giovanni.Bajo | link | issue7213 messages |
2010-12-10 19:30:33 | Giovanni.Bajo | create | |
|