| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
…lative PATH entry When the interpreter is started by a bare program name and found through a relative directory in PATH, getpath left sys.executable as that relative path, contrary to its documented behaviour of being an absolute path. This is a regression from the getpath.c rewrite in 3.11. Absolutize the executable resolved from PATH, matching the sibling branch that already calls abspath() when the program name itself contains a separator.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
sys.executable is documented as "a string giving the absolute path of the executable binary for the Python interpreter". When the interpreter is started by a bare program name (no separator) and found through a relative directory in PATH, it was left as that relative path instead:
getpath absolutizes the executable in the sibling branch that handles a program name containing a separator (executable = abspath(program_name)), but the PATH-resolution loop assigned the joined path directly. This makes it call abspath() there too:
This is a regression from the getpath.c rewrite in 3.11 (bpo-45582 / #29041); 3.10 returned an absolute path.
The issue also notes a separate, cosmetic double-slash case (//usr/local/bin/python3 when invoked as usr/local/bin/python3 from /); that comes from a different branch and is not addressed here.