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 <[EMAIL PROTECTED]> 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@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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com