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
Expose os.posix_spawnp() #79855
Comments
bpo-20104 exposed os.posix_spawn(), but not os.posix_spawnp(). os.posix_spawnp() would be useful to support executable with no directory. See bpo-35537 "use os.posix_spawn in subprocess". I'm not sure what is the best API:
execvp() uses the PATH environment variable, or use confstr(_CS_PATH) if PATH is not set. I guess that posix_spawnp() also uses confstr(_CS_PATH) if PATH is not set. Currently, my favorite option is to add a new optional 'use_path' parameter to the existing os.posix_spawn() function. |
Historically, Python used to mimick the libc: there are os.stat() and os.lstat() for example. But later, os.stat(*, follow_symlinks=False) keyword-only parameter has been added: if true, lstat() is used internally. |
To add some context, the follow_symlinks parameter was added to os.stat() after adding support of *at() functions (like openat() and fstatat()). Since both C functions stat() and lstat() are superseded by fstatat(), the latter was exposed at Python level as adding new keyword-only parameters to os.stat(). This allowed to avoid significant increasing the number of functions in the os module. Since there is no function that supersedes both posix_spawn() and posix_spawnp(), this may be an argument for exposing them as separate functions at Python level. Although this argument is not very strong. |
I would go with exposing posix_spawnp() as a separate function to rule out any arguments. I am working on this in this regard unless anyone has a different view. |
I'm ok to expose posix_spawnp() as os.posix_spawnp(). Even if we expose posix_spawnp() as os.posix_spawnp(), we can still reconsider to add posix_spawnp() feature into os.posix_spawn() as an optional keyword parameter later :-) Honestly, I have no strong preference for the API. My main problem with the keyword option is the risk of name conflict if a new feature is added to posix_spawn() with a name similar to my proposed name "use_path". |
I also think to expose posix_spawnp() as os.posix_spawnp() seems the more consistent thing to do as the os/posix module tries to mirror glibc as much as possible, which helps with discoverability and cross-reference with man pages. |
Pablo:
Ok. Let's do that. @joannah Nanjekye: Don't hesitate to come to me if you need my help to implement that ;-) |
Now that there is consesus, I am working on a PR for this. |
Well done Joannah Nanjekye :-) Thanks to Joannah for this nice enhancemenet and to all reviewers. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: