[Python-Dev] Python program name

[Vinay Sajip]

IIUC, the program name of the Python executable is set to whatever argv[0] is.
Is there a reason for this, rather than using one of the various OS-specific
APIs [1] for getting the name of the running executable? The reason I ask is
that in a virtual environment (venv), the exe's path is the only thing you have
to go on, and if you don't have that, you can't find the pyvenv.cfg file and
hence the base Python from which the venv was created.

Of course argv[0] is normally set to the executable's path, but there's at least
one test (in test_sys) where Python is spawned (via subprocess) with argv[0] set
to "nonexistent". If run from a venv created from a source build, with no Python
3.3 installed, this test fails because the spawned Python can't locate the
locale encoding, and bails.

It works when run from a source build ("./python ...") because the getpath.c
code to find a prefix looks in the directory implied by argv[0] (in the case of
"nonexistent" => "", i.e. the current directory) for "Modules/Setup", and also
works from a venv if created from an installed Python 3.3 (since the value of
sys.prefix is used as a fallback check, and that value will contain that
Python). However, when run from a venv created from a source build, with no
Python 3.3 installed, the error occurs.

A workaround might be one of these:

1. Use an OS-specific API rather than argv[0] to get the executable's path for
the processing done by getpath.c in all cases, or

2. If the file named by argv[0] doesn't exist, then use the OS-specific API to
find the executable's path, and try with that, or

3. If using the current logic, no prefix is found, then use the OS-specific API
to to find the executable's path, and try with that.

I would prefer to use option 2 and change getpath.c / getpathp.c accordingly.
Does anyone here see problems with that approach?

Regards,

Vinay Sajip

[1] http://stackoverflow.com/a/933996