[Python-Dev] towards a stricter definition of sys.executable (original) (raw)

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?

--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.pythonexecutable 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 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