[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)
> 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.
> 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.
> Python-Dev mailing list
> Python-Dev at python.org
> 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