I’ve been hacking away at a proof-of-concept library to simplify interacting with external subprocesses, and am interested in feedback, and gauging interest in it.
The new library wraps underlying concepts such as pid and file descriptor style identifiers such as pidfds/process descriptors/handles etc. As much as possible it offers end-to-end management of processes using the best available identifier avoiding pid races and offering blocking (rather than busy) waits. It also offers access to some of the more esoteric features available on some platforms.
Additionally, it offers the concept of a unique_id for a process, which can be used when it’s not possible to maintain a file descriptor - for example via pickling, or across multiple invocations of a script that needs to attach to the same process reliably.
Sounds interesting Nick. But for a third party plug-in library, putting your code and Readme, on top of a fork, of the entire CPython code base makes it difficult, even impossible, to focus on the parts of it you’ve changed, that are relevant for the design purpose.
Assuming the intetion isn’t for the user to use a whole different build of a CPython fork, not install a library into nroaml CPython at all?
I’m not sure I exactly follow - This isn’t a ‘3rd party plugin library’ - this is something that might be merged into cpython one day; Essentially it’s a proof of concept to get feedback.
I considered making this a standalone module, but effectively that meant re-implementing much of subprocess; One of its main benefits is working seamlessly with subprocesss.
Might I suggest you start at the “Points of Interest” section of the readme.
It’s a third party fork then, not a third party library. Even so a PR is a lot easier to review, than the entire source tree.
Is there any reason this can’t be repackaged as, and published as a third party library? It would be a lot easier for people to give you feedback then. Does it require any particular alterations to core runtime?
I’m still not certain what ‘3rd party’ means here. Isn’t any code that’s not merged into cpython “3rd party”? I don’t think this is an especially useful designator.
>Is there any reason this can’t be repackaged as, and published as a third party library? It would >be a lot easier for people to give you feedback then. Does it require any particular alterations to >core runtime?
Yes - Much (though not all) of its value comes from integration with subprocess. It doesn’t touch the interpreter at all, but it does modify subprocess and _posixsubprocess. Not massively, but also not trivially either.
The rationale behind putting this in the stdlib is that Python currently offers launching and management of subprocesses via subprocess (amongst others) via the stdlib and this improves that at zero cost to the user (usually no code changes required), as well as expanding this capability to processes that aren’t children of the current process.
I didn’t create a pull request because that seemed a bit forward (plus it’s not remotely close to being ready) I could do so if you want.