[Python-Dev] Python program name (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Fri May 4 10:44:25 CEST 2012


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



More information about the Python-Dev mailing list