Repository navigation
sys.executable generating canonical path #58296
Description
Activity
Hi all,
As it is my first time here, I'll try to explay step-by-step why I'm providing this path, and why I think that it is changing something that I believe that is not correct.
First of all, I was trying to run one individual test, as the dev guide says:
./python -m test -v test_sys
but, instead of run this test from the root directory of the project, I run it from ./Lib/test, so I did:
../../python -m test -v test_sys
and it returned an error. The reason is that my sys.executable was not an abspath. When I went to see why it is different, I get this value to sys.executable:
sys.executable -> '/home/antonio/Projects/cpython/Lib/test/../../python'
I'm not sure if I'm thinking write, but for me don't look nice to have this value as sys.executable, once the real path should be:
'/home/antonio/Projects/cpython/python'
So I'm providing a paatch that do exactly this.
Hope you enjoy
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Feb 22, 2012 This is unfortunately wrong since it will fail in the face of symlinks.
(if "foo" is a symlink to another directory, then "foo/../bar" is not the same thing as "bar")We can use realpath() if the function is available. Something similar is already done for sys.argv[0]. We should also use GetFullPathNameW() on Windows.
See also the issue bpo-13402.
We can use realpath() if the function is available. Something similar
is already done for sys.argv[0]. We should also use GetFullPathNameW()
on Windows.GetFullPathName() is an abspath() equivalent. For realpath() you want
GetFinalPathNameByHandle(), aka. _nt.getfinalpathname().GetFullPathName() is an abspath() equivalent. For realpath() you
want GetFinalPathNameByHandle(), aka. _nt.getfinalpathname().Ah? ntpath.realpath() uses nt._getfullpathname(). Is it a bug in ntpath?
Ah? ntpath.realpath() uses nt._getfullpathname(). Is it a bug in ntpath?
Probably:
# realpath is a no-op on systems without islink support realpath = abspath
> Is it a bug in ntpath?
ProbablyOk, I opened the issue bpo-14094.
I wonder if the doc for sys.executable should mention that .. segments may be present.
Éric Araujo wrote:
I wonder if the doc for sys.executable should mention that ..
segments may be present.Once this is fixed, it should say that .. segments may be present if
there's realpath() is not available.This is still unresolved:
iritkatriel@Irits-MBP Lib % pwd
/Users/iritkatriel/src/cpython-1/Lib
iritkatriel@Irits-MBP Lib % ../python.exe -m test -v test_sys[snipped]
======================================================================
FAIL: test_executable (test.test_sys.SysModuleTest)
----------------------------------------------------------------------Traceback (most recent call last): File "/Users/iritkatriel/src/cpython-1/Lib/test/test_sys.py", line 692, in test_executable self.assertEqual(os.path.abspath(sys.executable), sys.executable) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError: '/Users/iritkatriel/src/cpython-1/python.exe' != '/Users/iritkatriel/src/cpython-1/Lib/../python.exe' - /Users/iritkatriel/src/cpython-1/python.exe + /Users/iritkatriel/src/cpython-1/Lib/../python.exe ? +++++++- addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory3.9 (EOL)end of lifeend of life3.10 (EOL)end of lifeend of life3.11only security fixesonly security fixes
on Aug 27, 2021 test_sys:
def test_executable(self): # sys.executable should be absolute self.assertEqual(os.path.abspath(sys.executable), sys.executable)
IMO the test is wrong. It must test: test.assertTrue(os.path.isabs(sys.executable)).
The path is not required to be normalized.
The path is not required to be normalized.
I'm talking about the current implementation.
I'm not against making Python even better: attempt to normalize the path ;-)
I'm not against making Python even better: attempt to normalize the path ;-)
I would be very cautious about doing that. I'm pretty sure it would break some existing code.
See also bpo-20443 "__code__. co_filename should always be an absolute path". I had a revert a change which affected sys.argv[0]:
commit a1a99b4
Author: Victor Stinner <vstinner@python.org>
Date: Mon Dec 9 17:34:02 2019 +0100bpo-20443: No longer make sys.argv[0] absolute for script (GH-17534) In Python 3.9.0a1, sys.argv[0] was made an asolute path if a filename was specified on the command line. Revert this change, since most users expect sys.argv to be unmodified.- addedpendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is providedand removed3.11only security fixesonly security fixes3.10 (EOL)end of lifeend of life3.9 (EOL)end of lifeend of life
on Aug 10, 2026 Given the probability of breaking user code, setting as pending. Please revert if this is deemed desirable.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: