Title: sys.executable default and altinstall
Type: behavior Stage: test needed
Components: Interpreter Core Versions: Python 3.5
Status: open Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, allan, barry, eric.araujo, eryksun, iritkatriel, loewis, ncoghlan, piotr.dobrogost, r.david.murray, stephane
Priority: normal Keywords: easy

Created on 2011-01-05 12:51 by allan, last changed 2021-08-07 17:33 by eryksun.

Messages (11)
msg125420 - (view) Author: Allan McRae (allan) Date: 2011-01-05 12:51
when sys.executable is run with a modified argv[0] such as:

> sh -c "exec -a '' /usr/bin/python2.7 -c 'import sys; print(sys.executable)'"

it returns some a hardcoded value.   In this case, it returns /usr/bin/python.   This value is likely wrong when python is installed with "make altinstall".

A possible solution is to modify the "progname" variable in Python/pythonrun.c to include the version in it so that the hardcoded return value is the most version specific binary.  I.e.

static char *progname = "python2.7";
msg125444 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-01-05 18:14
Another alternative might be to return "None" ("refuse the temptation to guess").  But, given the long standing nature of the current guessing, having it return the specific version string may indeed make sense.
msg125458 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2011-01-05 19:30
For Python < 3.2, I think adding the version number alone makes sense.  Can you think of any situations where the trailing digits could break something?

For Python 3.2 I'd suggest also adding the build flags to sys.executable.  If you want the most specific binary, that would make the most sense.
msg125469 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-01-05 21:02
Well, the digits are there if they are there in the name when that's actually what is in argv[0], so as long as that's the name the binary is actually installed under I don't think it will break anything.  I presume the same applies to the abi flags but haven't checked.

That said, I don't know for sure that progname is the right thing to change; I haven't looked through the code to see how sys.executable is generated or if there is anything else GetPythonName is used for.

Hmm.  I suppose there could be an issue if Python is invoked through a wrapper...I know Gentoo does that, so I've added Arfrever to nosy to see if he has an opinion.
msg125475 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-01-05 21:58
I rather doubt that there will be any problem with Python invoked through a wrapper.
Gentoo's python-wrapper isn't used when target executable (e.g. /usr/bin/python3.1) is directly called.  A side effect of python-wrapper is that sys.executable is the target executable:
$ readlink /usr/bin/python
$ /usr/bin/python -c 'import sys; print(sys.executable)'
$ /usr/bin/python-wrapper -c 'import sys; print(sys.executable)'
$ sh -c "exec -a '' /usr/bin/python -c 'import sys; print(sys.executable)'"
$ sh -c "exec -a '' /usr/bin/python3.1 -c 'import sys; print(sys.executable)'"

If there is a patch, then I can test it.
msg125598 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-01-06 22:36
I fail to see the bug. Garbage in, garbage out. AFAIU, returning /usr/bin/python2.7 still might be the wrong answer.
msg125611 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-01-07 01:13
I agree that not guessing would be better.  But as long as we *are* guessing, it seems to me that /usr/bin/python2.7 would be less wrong than /usr/bin/python, for almost all modern unix systems.
msg125627 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-01-07 06:58
> I agree that not guessing would be better.

Well, on Linux, readlink("/proc/self/exe") would be better than
msg213132 - (view) Author: Piotr Dobrogost (piotr.dobrogost) Date: 2014-03-11 09:28
> Garbage in, garbage out.

In this case – exec -a '' – yes, but in general not so – see "Mismatch between sys.executable and sys.version in Python" question at SO (

As to not guessing Victor STINNER in comment wrote this:

There are different methods to get the real program name, but no one is portable. As flox wrote, we can "do a best effort to provide a valid sys.executable". Extract of stackoverflow link:

 * Mac OS X: _NSGetExecutablePath() (man 3 dyld)
 * Linux: readlink /proc/self/exe
 * Solaris: getexecname()
 * BSD with procfs: readlink /proc/curproc/file
 * Windows: GetModuleFileName() with hModule = NULL
msg399177 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-08-07 11:21
I can't reproduce this on 3.11, and I don't see a "progname" variable in Python/pythonrun.c.

I will close this unless someone will indicate it is still relevant.
msg399196 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-08-07 17:33
In 3.2, the default program name on non-Windows systems was changed to "python3" (see bpo-15020). In 3.5, the code was moved into Python/pylifecycle.c (see bpo-22869). Between 3.7 and 3.8, the initialization code was rewritten (see PEP 587). Currently it's set in config_init_program_name() in Python/initconfig.c. On POSIX systems, calculate_which() in Modules/getpath.c searches PATH to resolve the name if it has no path separator. For example:

    $ bash -c 'exec -a "" python -c "import sys; print(repr(sys.executable))"'

The default "python3" program name isn't used if C argv[0] is non-empty, in which case calculate_which() may or may not find the given program name:

    $ bash -c 'exec -a "ls" python -c "import sys; print(repr(sys.executable))"'

    $ bash -c 'exec -a "py" python -c "import sys; print(repr(sys.executable))"'

In Windows, the default program name is "python", but this isn't relevant for sys.executable, which is based on GetModuleFileNameW(NULL, ...) instead. This is similar to using readlink("/proc/self/exe", ...) in Linux, except the loader in Windows, and thus GetModuleFileNameW(), does not resolve symlinks in the file path.
Date User Action Args
2021-08-07 17:33:06eryksunsetstatus: pending -> open
nosy: + eryksun
messages: + msg399196

2021-08-07 11:21:51iritkatrielsetstatus: open -> pending

nosy: + iritkatriel
messages: + msg399177

resolution: out of date
2014-03-18 04:36:21eric.araujosetversions: + Python 3.5, - Python 3.1, Python 2.7, Python 3.2
2014-03-11 09:28:54piotr.dobrogostsetnosy: + piotr.dobrogost
messages: + msg213132
2011-01-09 01:17:02eric.araujosetnosy: + eric.araujo
2011-01-07 06:58:39loewissetnosy: loewis, barry, ncoghlan, Arfrever, r.david.murray, allan, stephane
messages: + msg125627
2011-01-07 01:13:34r.david.murraysetnosy: loewis, barry, ncoghlan, Arfrever, r.david.murray, allan, stephane
messages: + msg125611
2011-01-06 22:36:36loewissetnosy: + loewis
messages: + msg125598
2011-01-06 12:25:22stephanesetnosy: + stephane
2011-01-05 21:58:25Arfreversetnosy: barry, ncoghlan, Arfrever, r.david.murray, allan
messages: + msg125475
2011-01-05 21:02:37r.david.murraysetnosy: + Arfrever
messages: + msg125469
2011-01-05 19:30:12barrysetnosy: barry, ncoghlan, r.david.murray, allan
messages: + msg125458
2011-01-05 18:31:26pitrousetnosy: + barry
2011-01-05 18:20:58r.david.murraysetnosy: + ncoghlan
2011-01-05 18:14:37r.david.murraysettype: behavior
versions: - Python 2.6, Python 2.5, Python 3.3
keywords: + easy
nosy: + r.david.murray

messages: + msg125444
stage: test needed
2011-01-05 12:51:33allancreate