Function multiple arguments assignment

It's likely this has already been proposed in past, I don't know, anyway... This occurred to me while using subprocess module yesterday. I had to do something like this: subprocess.Popen(["exe"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE) Would it be appropriate to permit something similar to multiple variable assignment such as: subprocess.Popen(["exe"], stdin=stdout=stderr=subprocess.PIPE) ...? Regards --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/psutil

+0 While this makes sense when I think it about it, it doesn't make sense when I feel about it. On Tue, Mar 22, 2011 at 5:16 AM, Giampaolo Rodolà <g.rodola@gmail.com>wrote:
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

On Tue, Mar 22, 2011 at 7:16 PM, Giampaolo Rodolà <g.rodola@gmail.com> wrote:
Hitting a gnat with a hammer. Something that may make more sense is a PopenPipe that changes the default for stdin/out/err to be distinct pipes rather than inherited from the parent (but still able to be set explicitly). It is certainly annoying that creating a fully piped subprocess is so verbose. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 22 March 2011 10:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
Yes. This always struck me as a (minor, but annoying) usability issue with subprocess rather than a difficulty crying out for a new language feature :-) Note that part of the problem is all those "subprocess." prefixes. Using from subprocess import * is so tempting here... :-) Paul.

On Wed, Mar 23, 2011 at 12:57 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Note that part of the problem is all those "subprocess." prefixes. Using from subprocess import * is so tempting here... :-)
As Antoine noted, selective direct imports definitely reduce the verbosity, as do things like simply abbreviating the module name. Using the convenience helpers (like subprocess.call()) when applicable also helps. There's probably room for another helper or two, though - e.g. I think there's a patch on the tracker somewhere that makes it easy to create threaded background readers to keep the stdout and stderr pipes from filling up and blocking the child process. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Paul Moore wrote:
On 22 March 2011 10:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
subprocess.Popen(["exe"], stdin=stdout=stderr=subprocess.PIPE)
Perhaps subprocess.Popen could have a 'default' argument specifying what to do for unspecified file descriptors. Then the above could be written subprocess.Popen(["exe"], default = subprocess.PIPE) -- Greg

On Tue, Mar 22, 2011 at 3:47 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Not to be too pointed about it, but IMO the last thing subprocess.Popen needs is more keyword arguments. I realize that it needs to be many things to many people, but its signature already requires >50 lines of documentation and a similar volume of example text to explain. To me, Nick Coghlan's more-helper-functions approach seems more sensible here. Geremy Condra

On Tue, Mar 22, 2011 at 8:35 PM, geremy condra <debatem1@gmail.com> wrote:
In other news, last week I needed to "detach" a subprocess, and thre is no high-level way to do it. There is very little documentation on this, one mostly has to follow C documentation using "for" and arcane system calls (os.setsid and os._exit) to get a process to be daemonized. Maybe subprocess could include a call to take care of all this mess - (or is it indeed only me who needs to detach processes? ) I followed the recipe from [1] and could not get it simpler [1] - http://stackoverflow.com/questions/972362/spawning-process-from-python

"Joao S. O. Bueno" <jsbueno@python.org.br> writes:
PEP 3143, and its reference implementation ‘python-daemon’, are my intended fix for this. I need to re-think how it uses lock files, but it is already useful for many people. The plan is to eventually get the ‘python-daemon’ implementation into the standard library, so there's then One Obvious Way To Do It. Please let me know how well it works for you. -- \ “Computer perspective on Moore's Law: Human effort becomes | `\ twice as expensive roughly every two years.” —anonymous | _o__) | Ben Finney

+0 While this makes sense when I think it about it, it doesn't make sense when I feel about it. On Tue, Mar 22, 2011 at 5:16 AM, Giampaolo Rodolà <g.rodola@gmail.com>wrote:
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

On Tue, Mar 22, 2011 at 7:16 PM, Giampaolo Rodolà <g.rodola@gmail.com> wrote:
Hitting a gnat with a hammer. Something that may make more sense is a PopenPipe that changes the default for stdin/out/err to be distinct pipes rather than inherited from the parent (but still able to be set explicitly). It is certainly annoying that creating a fully piped subprocess is so verbose. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 22 March 2011 10:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
Yes. This always struck me as a (minor, but annoying) usability issue with subprocess rather than a difficulty crying out for a new language feature :-) Note that part of the problem is all those "subprocess." prefixes. Using from subprocess import * is so tempting here... :-) Paul.

On Wed, Mar 23, 2011 at 12:57 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Note that part of the problem is all those "subprocess." prefixes. Using from subprocess import * is so tempting here... :-)
As Antoine noted, selective direct imports definitely reduce the verbosity, as do things like simply abbreviating the module name. Using the convenience helpers (like subprocess.call()) when applicable also helps. There's probably room for another helper or two, though - e.g. I think there's a patch on the tracker somewhere that makes it easy to create threaded background readers to keep the stdout and stderr pipes from filling up and blocking the child process. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Paul Moore wrote:
On 22 March 2011 10:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
subprocess.Popen(["exe"], stdin=stdout=stderr=subprocess.PIPE)
Perhaps subprocess.Popen could have a 'default' argument specifying what to do for unspecified file descriptors. Then the above could be written subprocess.Popen(["exe"], default = subprocess.PIPE) -- Greg

On Tue, Mar 22, 2011 at 3:47 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Not to be too pointed about it, but IMO the last thing subprocess.Popen needs is more keyword arguments. I realize that it needs to be many things to many people, but its signature already requires >50 lines of documentation and a similar volume of example text to explain. To me, Nick Coghlan's more-helper-functions approach seems more sensible here. Geremy Condra

On Tue, Mar 22, 2011 at 8:35 PM, geremy condra <debatem1@gmail.com> wrote:
In other news, last week I needed to "detach" a subprocess, and thre is no high-level way to do it. There is very little documentation on this, one mostly has to follow C documentation using "for" and arcane system calls (os.setsid and os._exit) to get a process to be daemonized. Maybe subprocess could include a call to take care of all this mess - (or is it indeed only me who needs to detach processes? ) I followed the recipe from [1] and could not get it simpler [1] - http://stackoverflow.com/questions/972362/spawning-process-from-python

"Joao S. O. Bueno" <jsbueno@python.org.br> writes:
PEP 3143, and its reference implementation ‘python-daemon’, are my intended fix for this. I need to re-think how it uses lock files, but it is already useful for many people. The plan is to eventually get the ‘python-daemon’ implementation into the standard library, so there's then One Obvious Way To Do It. Please let me know how well it works for you. -- \ “Computer perspective on Moore's Law: Human effort becomes | `\ twice as expensive roughly every two years.” —anonymous | _o__) | Ben Finney
participants (9)
-
Antoine Pitrou
-
Ben Finney
-
Calvin Spealman
-
geremy condra
-
Giampaolo Rodolà
-
Greg Ewing
-
Joao S. O. Bueno
-
Nick Coghlan
-
Paul Moore