Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate subprocess32 #51

Open
nirs opened this issue Dec 10, 2016 · 11 comments
Open

Integrate subprocess32 #51

nirs opened this issue Dec 10, 2016 · 11 comments

Comments

@nirs
Copy link
Contributor

nirs commented Dec 10, 2016

Already ported to 2.7, should be easy to integrate:
https://github.com/google/python-subprocess32

@naftaliharris
Copy link
Owner

Hmm, shouldn't be too bad probably.

A quick look at the 3.5.2 version of subprocess shows that it requires time.monotonic, which I've been meaning to do as it's a dependency for some of the async-type stuff. But maybe makes sense to do 3.2 version of subprocess first as it's already done...

@kovidgoyal
Copy link
Contributor

@dan-stromberg
Copy link

I submitted a pull request to the subprocess32 project to make subprocess32 build on tauthon. Someone e-mailed me back indicating it'd be better to merge subprocess32 into tauthon than to patch subprocess32 to work out of the box on tauthon.

@arizvisa
Copy link
Contributor

@dan-stromberg, what's the PR# (or your branch) that you submitted to subprocess32?

@dan-stromberg
Copy link

dan-stromberg commented Sep 23, 2019 via email

@arizvisa
Copy link
Contributor

thx, sir.

I'm working on time.monotonic* right now. I'll look at how to include your PR afterwards.

@dan-stromberg
Copy link

dan-stromberg commented Sep 23, 2019 via email

@arizvisa
Copy link
Contributor

I just submitted Python3's time.monotonic functions as PR #122 (excluding time.get_clock_info). If something needs that lmk, and I can work on implementing that in the next couple days.

It needs testing for OSX as I don't have access to that platform. Actually it probably needs testing against whatever consumes it as I just wrote it up and submitted the PR a few minutes ago....

@arizvisa
Copy link
Contributor

So the internal _subprocess and _posixsubprocess modules can probably be merged so that fork_exec is exposed on both platforms (and backwards compatibility can be maintained). Then anything that depends on these binary modules can just use whatever is necessary.

However, are there any other differences in the subprocess module between Python2 and Python3? If we simply replace Lib/subprocess.py with Python3's version, will that potentially break modules that depend on Python2's implementation? Is this something that we can just get away with, or would it just be safer in terms of compatibility to have it as a separate module similar to subprocess32?

@stefantalpalaru
Copy link
Collaborator

If we simply replace Lib/subprocess.py with Python3's version, will that potentially break modules that depend on Python2's implementation? Is this something that we can just get away with

No, it isn't. Backwards compatibility is a very high priority for us - comes right after security.

@arizvisa
Copy link
Contributor

arizvisa commented Oct 1, 2019

I suppose it wasn't too clear, but according to https://docs.python.org/3/whatsnew/3.7.html, the differences seem to be that subprocess.run contains a capture_output keyword, an alias for universal_newlines as text, context manager for Popen, better handling of KeyboardInterrupt (by adding a delay), and `close_fds is now defaulted to true.

Other than close_fds, all of these things seem backwards-compatible. Is this all that's different between these interfaces?

Personally instead of using the subprocess interface, I prefer just having access to handles/fds and feeding i/o to coroutines that use yield as an expression, so I'm totally unfamiliar with the differences between both of the subprocess implementations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants