classification
Title: Document absoluteness of sys.executable
Type: Stage: resolved
Components: Documentation Versions: Python 3.2, Python 3.3, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: blarsen, dino.viehland, docs@python, eli.bendersky, eric.araujo, eric.snow, eryksun, flox, ned.deily, petri.lehtinen, pitrou, pjenvey, python-dev, ronaldoussoren, schmir, vstinner
Priority: normal Keywords: patch

Created on 2011-11-14 16:50 by eric.araujo, last changed 2016-07-12 03:05 by ned.deily. This issue is now closed.

Files
File name Uploaded Description Edit
issue13402.patch petri.lehtinen, 2011-11-20 20:09 review
issue13402_v2.patch petri.lehtinen, 2011-12-14 19:28 review
issue13402_v3.patch petri.lehtinen, 2012-01-31 19:10 review
Messages (20)
msg147609 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-14 16:50
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.)
msg148006 - (view) Author: Petri Lehtinen (petri.lehtinen) * (Python committer) Date: 2011-11-20 20:09
Attached a patch.
msg148029 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2011-11-21 04:28
LGTM
msg148042 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-21 13:50
Patch looks good, but are you 100% sure that sys.executable is always absolute?  (On all OSes, under multiprocessing, etc?)
msg148043 - (view) Author: Petri Lehtinen (petri.lehtinen) * (Python committer) Date: 2011-11-21 14:20
É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.
msg148317 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-25 15:00
This is the bug I was thinking about: #7774.  Adding some people from that discussion to nosy.
msg148355 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-11-25 19:51
LGTM too.
You could also add a test to test_sys ensuring that sys.executable is always executable.
msg148356 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-11-25 20:04
> 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.
msg148357 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-11-25 20:11
> > 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.
msg149468 - (view) Author: Petri Lehtinen (petri.lehtinen) * (Python committer) Date: 2011-12-14 19:28
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.
msg149483 - (view) Author: Philip Jenvey (pjenvey) * (Python committer) Date: 2011-12-14 23:11
sys.executable can be None on Jython (and I believe IronPython) when ran in an 'embedded' mode
msg149511 - (view) Author: Petri Lehtinen (petri.lehtinen) * (Python committer) Date: 2011-12-15 07:09
> 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.
msg150460 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-01-02 15:58
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)).
msg152403 - (view) Author: Petri Lehtinen (petri.lehtinen) * (Python committer) Date: 2012-01-31 19:10
Attached one more patch. The documentation now also mentions None as a possible value.
msg152473 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-02-02 19:30
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
msg270210 - (view) Author: Brad Larsen (blarsen) * Date: 2016-07-11 22:06
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
msg270217 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2016-07-12 00:35
"/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.
msg270222 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-07-12 02:39
@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.
msg270223 - (view) Author: Brad Larsen (blarsen) * Date: 2016-07-12 02:59
@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?
msg270224 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-07-12 03:05
@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.
History
Date User Action Args
2016-07-12 03:05:43ned.deilysetmessages: + msg270224
2016-07-12 02:59:08blarsensetmessages: + msg270223
2016-07-12 02:39:28ned.deilysetnosy: + ned.deily
messages: + msg270222
2016-07-12 00:35:28eryksunsetnosy: + eryksun
messages: + msg270217
2016-07-11 22:06:12blarsensetnosy: + blarsen
messages: + msg270210
2012-02-02 19:30:22python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg152473

resolution: fixed
stage: resolved
2012-01-31 19:10:36petri.lehtinensetfiles: + issue13402_v3.patch

messages: + msg152403
2012-01-02 15:58:34eric.araujosetmessages: + msg150460
2011-12-15 07:09:33petri.lehtinensetmessages: + msg149511
2011-12-14 23:11:28pjenveysetnosy: + pjenvey, dino.viehland
messages: + msg149483
2011-12-14 19:28:54petri.lehtinensetfiles: + issue13402_v2.patch

messages: + msg149468
2011-11-25 20:11:41pitrousetmessages: + msg148357
2011-11-25 20:04:24vstinnersetmessages: + msg148356
2011-11-25 19:51:31pitrousetmessages: + msg148355
2011-11-25 15:00:07eric.araujosetnosy: + ronaldoussoren, pitrou, vstinner, schmir, flox
messages: + msg148317
2011-11-21 20:08:03eric.snowsetnosy: + eric.snow
2011-11-21 14:20:04petri.lehtinensetmessages: + msg148043
2011-11-21 13:50:02eric.araujosetmessages: + msg148042
2011-11-21 04:28:26eli.benderskysetnosy: + eli.bendersky
messages: + msg148029
2011-11-20 20:09:07petri.lehtinensetfiles: + issue13402.patch
keywords: + patch
messages: + msg148006
2011-11-19 10:50:21petri.lehtinensetnosy: + petri.lehtinen
2011-11-14 16:50:37eric.araujocreate