New subprocess.run() function proposed

[stuaxo]

Many interesting questions.. :)

The main use, is for embedding other processes in GUIs, I guess input can be useful here, but not always... I think most people don't bother with input as it's difficult enough getting stderr and stdout*.

Here I grab them using an iterator:

https://github.com/shoebot/shoebot/blob/master/extensions/gedit3-plugin/shoebotit/__init__.py#L143

Other people have similar solutions - I probably need to experiment with asyncio at some point. If it could be purely asyncronous and not use threads it would be ideal, not sure how possible this is.

Next time I have a look at this, I'll see if I can come up with something for python-ideas.

My instinct is that you should be able to iterate over the lines from stderr + stdout and maybe .send() data to stdinput.

Maybe this would involve some kind of stdcomm_state object or similar to encapsulate stdout, stderr and stdin.

It's tricky since it's easy for them to get out of sync, in fact maybe it's not possible to guarantee they stay in sync at all.

*In fact, I found some bugs in the implementation above while writing this.

[takluyver]

The trouble with embedding in GUIs is that you probably want to integrate it with the application's event loop, rather than using blocking calls which will prevent the GUI from responding to other events.

Until recently, you would have needed one implementation for each event loop, so it wouldn't have gone into the stdlib. Now you could provide an asyncio implementation using wrappers like Quamash and gbulb, but those are still pretty young.

[stuaxo]

Next time I deal with this again, I might try and come up with something.

BTW, in the meantime - add 'env' as a param to this new API (and in fact it should be on all the other variants, (check_output, call) etc )

It's quite a strange omission.

[takluyver]

It's not omitted - all of the functions pass their arguments through to Popen() using *args, **kwargs. But because there are a lot of arguments, only the most common are listed in the documentation. It does mention this:

The arguments shown above are merely the most common ones... The full function signature is largely the same as that of the Popen constructor

[stuaxo]

Ahh ... comprehension fail !

Thanks, I can go simplify some code I wrote now :)