homepage

I wanted to know if sys.executable was always an absolute path but the doc does not talk about that.
(My use case is that I’d like to reload a process and I wonder if I can call os.execve or if I need to use os.execvpe.)

Attached a patch.

LGTM

Patch looks good, but are you 100% sure that sys.executable is always absolute? (On all OSes, under multiprocessing, etc?)

Éric Araujo wrote:
> Patch looks good, but are you 100% sure that sys.executable is
> always absolute? (On all OSes, under multiprocessing, etc?)
Well, its value is computed by a function named
Py_GetProgramFullPath(), so I'm quite sure. I had a quick look on what
the function is doing, but it was quite complicated. I can check it
better if needed.

This is the bug I was thinking about: #7774. Adding some people from that discussion to nosy.

LGTM too.
You could also add a test to test_sys ensuring that sys.executable is always executable.

> You could also add a test to test_sys ensuring that sys.executable
> is always executable.
And that sys.executable is absolute?
sys.executable is an empty string if sys.argv[0] has been changed and Python is unable to retrieve the real path to the Python executable. See the issue #7774. The fact that sys.executable can be empty should be documented.

> > You could also add a test to test_sys ensuring that sys.executable
> > is always executable.
> 
> And that sys.executable is absolute?
Er, yes, that's what I meant. Sorry.

Attaching an updated patch. The documentation now says that sys.executable may be an empty string. The patch also adds a test to make sure that sys.executable is absolute.

sys.executable can be None on Jython (and I believe IronPython) when ran in an 'embedded' mode

> sys.executable can be None on Jython (and I believe IronPython) when ran in an 'embedded' mode
In CPython, embedding doesn't change the behavior.

This discussion seems relevant: http://mail.python.org/pipermail/python-dev/2006-March/062453.html (it talks about the meaning of sys.executable, special cases such as embedded Python and functions that implement it (so we can have a look at that code)).

Attached one more patch. The documentation now also mentions None as a possible value.

New changeset fdcda5b74317 by Petri Lehtinen in branch '3.2':
Document absoluteness of sys.executable
http://hg.python.org/cpython/rev/fdcda5b74317
New changeset 8b591a86fc91 by Petri Lehtinen in branch 'default':
Merge branch 3.2
http://hg.python.org/cpython/rev/8b591a86fc91
New changeset c351536e804a by Petri Lehtinen in branch '2.7':
Document absoluteness of sys.executable
http://hg.python.org/cpython/rev/c351536e804a 

It looks like sys.executable is *not* always an absolute path. In Python 2.7:
 $ which python2.7
 /opt/local/bin/python2.7
 $ cd /opt/local/bin
 $ ../bin/python2.7 -m 'import sys; print(sys.executable)'
 /opt/local/bin/../bin/python2.7
Also in Python 3.5:
 $ which python3.5
 /opt/local/bin/python3.5
 $ cd /opt/local/bin
 $ ../bin/python3.5 -m 'import sys; print(sys.executable)'
 /opt/local/bin/../bin/python3.5

"/opt/local/bin/../bin/python2.7" is an absolute path. 
 >>> os.path.isabs('/opt/local/bin/../bin/python2.7')
 True
It's not relative to the working directory.

@blarsen, and there's something strange about your example. '-m' won't work with a real python executable, presumably you meant '-c'. And judging from the paths involved, I'm guessing you are using MacPorts on OS X. With either MacPorts or any other OS X framework build, you wouldn't see results like that with -c.
 ../bin/python3.5 -c 'import sys; print(sys.executable)'
/opt/local/bin/python3.5
../bin/python2.7 -c 'import sys; print(sys.executable)'
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
So I'm guessing what's in ../bin/python3.7 and ../bin/python3.5 is something other than the normal python bootstrap binaries.

@eryksun, you are right! The output *is* an absolute path as far as `os.path.isabs` is concerned.
@ned.deily, you are right about my example --- I transcribed it wrong, and it should be `-c`.
The system in question is not a Mac OS system, but a Linux system with newer Python versions than what come with the system installed to /opt/local. These are compiled from source, but without any modifications.
I'm commenting here because I'm seeing the `test_sys` test from the regression suite fail in a slightly modified version of Python that ships with a product. In particular, in Lib/test/test_sys.py around line 640, we have this:
 @unittest.skipIf(sys.base_prefix != sys.prefix,
 'Test is not venv-compatible')
 def test_executable(self):
 # sys.executable should be absolute
 self.assertEqual(os.path.abspath(sys.executable), sys.executable)
Yes, /opt/local/bin/../bin/python3.5 is an absolute path as far as `os.path.isabs` is concerned, but `os.path.abspath('/opt/local/bin/../bin/python3.5')` gives '/opt/local/bin/python3.5', and the test fails. So maybe the documentation is fine but the test is wrong?

@blarsen, OK, but if you want to pursue this, please open a new issue against the current versions. This issue was closed years ago and against earlier versions so your comments will not get acted on.