homepage

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 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:
> 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 ;-)

Now that there is consesus, I am working on a PR for this.

New changeset 92b8322e7ea04b239cb1cb87b78d952f13ddfebb by Victor Stinner (Joannah Nanjekye) in branch 'master':
bpo-35674: Add os.posix_spawnp() (GH-11554)
https://github.com/python/cpython/commit/92b8322e7ea04b239cb1cb87b78d952f13ddfebb

Well done Joannah Nanjekye :-) Thanks to Joannah for this nice enhancemenet and to all reviewers.

FYI I modified subprocess to use os.posix_spawnp() when it's available:
New changeset 07858894689047c77f9c12ddc061d30681368d19 by Victor Stinner in branch 'master':
bpo-35537: subprocess can now use os.posix_spawnp (GH-11579)
https://github.com/python/cpython/commit/07858894689047c77f9c12ddc061d30681368d19