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

[Guido van Rossum]

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?

--Guido

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/)