[Python-Dev] towards a stricter definition of sys.executable
Bob Ippolito
bob at redivi.com
Fri Mar 17 23:15:38 CET 2006
On Mar 17, 2006, at 12:40 AM, Martin v. Löwis wrote:
> Fredrik Lundh wrote:
>> I don't think many people embed setup.py scripts, so alternative
>> (e) would pro-
>> bably cause the least problems:
>>
>> e) sys.executable contains the full path to the program used
>> to invoke
>> this interpreter instance, or None if this could not be
>> determined.
>
> It seems that you indeed are trying to solve a problem you
> encountered.
> Can you please explain what the problem is?
>
> ISTM that the current definition doesn't really cause problems,
> despite
> potentially being fuzzy. People that start sys.executable typically
> *do* get a Python interpreter - in an embedded interpreter, they just
> don't want to start a new interpreter, as that couldn't work, anyway.
I've seen cases where people want to start worker processes from
bundled apps (as in py2app/py2exe). The bootstrap executable
(sys.executable) is not suitable for this purpose, as it runs a
specific script. Forking doesn't quite do the right thing either
because it's not safe to fork without exec'ing in all cases due to
state that persists that shouldn't across processes with certain
platform libraries (in Mac OS X especially).
For py2app, we can bundle a Python interpreter that links to the same
Python framework and has the same set of modules and extensions that
the bundled application does, so we can support this use case. I'd
definitely like to see something like sys.python_executable become
standard, and I think I'll go ahead and support it in the next
release of py2app.
It's possible to degrade gracefully with this approach too:
def get_python_executable():
python_executable = getattr(sys, 'python_executable', None)
if python_executable is not None:
return python_executable
if not sys.frozen and sys.executable:
# launched from a standard interpreter
return sys.executable
# frozen without python_executable support
raise RuntimeError
-bob
More information about the Python-Dev
mailing list