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/archive%40mail-archive.com
