homepage

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

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 #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?
> Probably
Ok, I opened the issue #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
? +++++++

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 a1a99b4bb7cbe2dbc55a1d92c3c509b4466d3c3b
Author: Victor Stinner <vstinner@python.org>
Date: Mon Dec 9 17:34:02 2019 +0100
 bpo-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.