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";

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.

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.

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.

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
python-wrapper
$ /usr/bin/python -c 'import sys; print(sys.executable)'
/usr/bin/python3.1
$ /usr/bin/python-wrapper -c 'import sys; print(sys.executable)'
/usr/bin/python3.1
$ sh -c "exec -a '' /usr/bin/python -c 'import sys; print(sys.executable)'"
/usr/bin/python3.1
$ sh -c "exec -a '' /usr/bin/python3.1 -c 'import sys; print(sys.executable)'"
/usr/bin/python

If there is a patch, then I can test it.

I fail to see the bug. Garbage in, garbage out. AFAIU, returning /usr/bin/python2.7 still might be the wrong answer.

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.

> I agree that not guessing would be better.

Well, on Linux, readlink("/proc/self/exe") would be better than
guessing.

> 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 (http://stackoverflow.com/q/22236727/95735).

As to not guessing Victor STINNER in comment http://bugs.python.org/issue7774#msg100849 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()
 * FreeBSD: sysctl CTL_KERN KERN_PROC KERN_PROC_PATHNAME -1
 * BSD with procfs: readlink /proc/curproc/file
 * Windows: GetModuleFileName() with hModule = NULL
"

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.

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))"'
    '/home/someone/.local/bin/python3'

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))"'
    '/usr/bin/ls'

    $ 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.