Repository navigation
Flag for unusable sys.executable #77361
Description
| BPO | 33180 |
|---|---|
| Nosy | @ncoghlan, @jwilk, @ericsnowcurrently, @zooba |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/zooba'
closed_at = <Date 2018-09-21.20:44:42.307>
created_at = <Date 2018-03-29.14:53:31.468>
labels = ['3.8', 'type-bug', '3.7', 'invalid']
title = 'Flag for unusable sys.executable'
updated_at = <Date 2018-09-21.20:44:42.306>
user = 'https://github.com/zooba'bugs.python.org fields:
activity = <Date 2018-09-21.20:44:42.306>
actor = 'steve.dower'
assignee = 'steve.dower'
closed = True
closed_date = <Date 2018-09-21.20:44:42.307>
closer = 'steve.dower'
components = []
creation = <Date 2018-03-29.14:53:31.468>
creator = 'steve.dower'
dependencies = []
files = []
hgrepos = []
issue_num = 33180
keywords = []
message_count = 5.0
messages = ['314655', '314656', '314660', '314661', '326036']
nosy_count = 4.0
nosy_names = ['ncoghlan', 'jwilk', 'eric.snow', 'steve.dower']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33180'
versions = ['Python 3.7', 'Python 3.8']
Activity
zooba commentedon Mar 29, 2018
If you host Python in another program, it's likely that sys.executable is not pointing to a normal Python interpreter. This can cause libraries such as multiprocessing to fail when they try to launch the interpreter again. Worse, it may have launched your application many more times before failure :)
I think we should add either a flag to indicate to any such library that sys.executable is not useful for relaunching Python, or a field that points to the actual executable but can safely be left None (or for most horrendous generality, a list of arguments to relaunch, as sometimes a command line option can get you into a normal interpreter). These would be set by embedders only, and Programs/python.c would set the "normal" values.
Thoughts?
zooba commentedon Mar 29, 2018
Looking at the docs https://docs.python.org/3/library/sys.html#sys.executable maybe we only need to clarify that it's not None only if it provides the normal command line? Then file bugs against all the libraries that don't work when it's not set?
ncoghlan commentedon Mar 29, 2018
I'm not sure what the right solution is at the design level, but I did recently run into a quirk related to this in the embedding tests: on \*nix systems, PySys_SetProgramName affects sys.executable, while Windows ignores it.
But certainly the intention is that a non-None sys.executable should be usable the way multiprocessing and the test suite use it: as a way to run Python in a subprocess. If an embedding environment wants to support that, it can set it to something suitable, and if it doesn't, it can set it to None.
(I do sometimes wonder if subprocess should have some sys.executable-specific helpers though - rerunning Python with the same settings as the current Python requires quite a bit more than just calling sys.executable with no particular options)
ncoghlan commentedon Mar 29, 2018
Also mentioning https://docs.python.org/3/library/multiprocessing.html#multiprocessing.set_executable, since it came up on the pickle-protocol-version-5 thread.
zooba commentedon Sep 21, 2018
Closing in favour of bpo-34725