You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Add os.posix_spawnp()? duplicate the documentation and some parts of the C code (but share most of the C code)
Add a new optional parameter to os.posix_spawn()? Ideas of names: 'use_path' or 'search_executable'. Internally, the glibc uses SPAWN_XFLAGS_USE_PATH flag to distinguish posix_spawn() and posix_spawnp().
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'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.
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.
Ok. Let's do that.
@joannah Nanjekye: Don't hesitate to come to me if you need my help to implement that ;-)
Activity
vstinner commentedon Jan 7, 2019
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.
vstinner commentedon Jan 7, 2019
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.
serhiy-storchaka commentedon Jan 7, 2019
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.
nanjekyejoannah commentedon Jan 8, 2019
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.
vstinner commentedon Jan 8, 2019
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".
pablogsal commentedon Jan 9, 2019
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.
vstinner commentedon Jan 9, 2019
Pablo:
Ok. Let's do that.
@joannah Nanjekye: Don't hesitate to come to me if you need my help to implement that ;-)
nanjekyejoannah commentedon Jan 10, 2019
Now that there is consesus, I am working on a PR for this.
vstinner commentedon Jan 16, 2019
New changeset 92b8322 by Victor Stinner (Joannah Nanjekye) in branch 'master':
bpo-35674: Add os.posix_spawnp() (GH-11554)
92b8322
vstinner commentedon Jan 16, 2019
Well done Joannah Nanjekye :-) Thanks to Joannah for this nice enhancemenet and to all reviewers.
vstinner commentedon Jan 16, 2019
FYI I modified subprocess to use os.posix_spawnp() when it's available:
New changeset 0785889 by Victor Stinner in branch 'master':
bpo-35537: subprocess can now use os.posix_spawnp (GH-11579)
0785889