[Python-Dev] towards a stricter definition of sys.executable

Guido van Rossum guido at python.org
Thu Mar 16 16:36:52 CET 2006

When I added this my intention was a mixture of (b) and (c) -- I
wasn't thinking of situations where there was a difference. (If you
remember Python's very early history, embedding wasn't something I had
anticipated -- hence the "Great Renaming".)

The use that I had in mind does things like os.system(sys.executable +
" foo.py") to run foo.py in a separate process. Any additional use
(e.g. digging data out of it or finding related files by parsing its
pathname) is a highly platform dependent activity; embedding can be
seen as a change in platform. For finding related files,
sys.exec_prefix and sys.prefix should be used. Digging data out of the
file itself never even occurred to me -- it assumes things like
executable format etc. that are typically beyond my understanding as a
portable language designer.

When Python is embedded in another app (e.g. mod_python), I would
expect sys.executable to be meaningless and its use to be undefined.
None would be a good value in that case. sys.prefix / exec_prefix may
or may not have a useful meaning in such an environment, depending on
how the standard library is made accessible.

Can you say more about the motivation for wanting this reinterpreted?


On 3/16/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> the definition of sys.executable is a bit unclear, something that has led to
> incompatible use in deployed code.
> the docstring for sys.executable says "pathname of this Python interpreter",
> which can be interpreted as either
>     a) sys.executable points to the executable that was used to load the
>     Python interpreter library/dll.
>     this use is supported by the docstring and the implementation, and is quite
>     common in the wild.  an application using this interpretation may
>     - call sys.executable to run another instance of itself
>     - extract data from resources embedded in (or attached to) sys.executable
>     - locate configuration data etc via os.path.dirname(sys.executable)
>     etc.
> or
>     b) sys.executable points to a standard Python interpreter executable of
>     the same version, and having the same library, as the currently running
>     interpreter instance.
>     this use is supported by more strict interpretation of the word "interpreter"
>     (as an executable, rather than an implementation DLL), and is quite common
>     in the wild.  an application using this interpretation may
>     - call sys.executable to run a Python script in the same environment as itself.
>     etc.
> or
>     c) sys.executable points to the file containing the actual ("this") interpreter.  I
>     haven't seen any code that assumes this, probably because no implementation
>     uses this interpretation...
> for programs that are invoked via the standard interpreter, case (a) and (b) are of
> course identical.
> the problem is when the interpreter library is embedded in some other application;
> should sys.executable be set to the actual EXE used to start the program, or to
> something else ?  if it's set to something else, how can that application do the things
> that's described under (a) ?
> to fix this, I propose adding another sys variable; for example, let sys.executable
> keep behaving like case (a) (which is how it's implemented today), and add a new
> sys.python_executable for case (b).  the latter can then be set to None if a proper
> interpreter cannot be located.
> </F>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list