Fix idlelib.PyShell.build_subprocess_arglist use of __import__

[terryjreedy]

BPO	18330
Nosy	@terryjreedy, @serwy

^{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/terryjreedy'
closed_at = <Date 2020-06-06.23:09:26.491>
created_at = <Date 2013-06-29.22:09:24.224>
labels = ['invalid', 'expert-IDLE', 'type-bug', '3.7']
title = 'Fix idlelib.PyShell.build_subprocess_arglist  use of __import__'
updated_at = <Date 2020-06-06.23:09:26.490>
user = 'https://github.com/terryjreedy'

bugs.python.org fields:

activity = <Date 2020-06-06.23:09:26.490>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2020-06-06.23:09:26.491>
closer = 'terry.reedy'
components = ['IDLE']
creation = <Date 2013-06-29.22:09:24.224>
creator = 'terry.reedy'
dependencies = []
files = []
hgrepos = []
issue_num = 18330
keywords = []
message_count = 5.0
messages = ['192053', '223281', '223294', '243333', '370858']
nosy_count = 2.0
nosy_names = ['terry.reedy', 'roger.serwy']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue18330'
versions = ['Python 3.6', 'Python 3.7']

[terryjreedy]

The purpose of the function is to create a command line for the user subprocess. Most of its body:
'''
# Maybe IDLE is installed and is being accessed via sys.path,
# or maybe it's not installed and the idle.py script is being
# run from the IDLE source directory.
del_exitf = idleConf.GetOption('main', 'General', 'delete-exitfunc',
default=False, type='bool')
if __name__ == 'idlelib.PyShell':
command = "__import__('idlelib.run').run.main(%r)" % (del_exitf,)
else:
command = "__import__('run').main(%r)" % (del_exitf,)
return [sys.executable] + w + ["-c", command, str(self.port)]
'''
Question: is it really important to avoid binding the run module to 'run' in the user process? If so, maybe we should use importlib.import_module, as 'direct use of __import__ is entirely discouraged".

The first command looks 'funny' because of the repetition of 'run'. The reason is that __import__('idlelib.run') returns idlelib, not idlelib.run. Perhaps it would work to delete .run in the import, or to use importlib.import_module.

The second command incorrectly assumes that if __name__ == '__main__' (the alternative to 'idlelib.PyShell'), then the directory containing PyShell and run is the current working directory. This is true if PyShell is run from that directory, but

F:\Python\dev\py33\PCbuild>python_d -m idlelib.PyShell
F:\Python\dev\py33\PCbuild>python_d ../Lib/idlelib/PyShell.py

both report "ImportError: No module named 'run'" and open a shell window and error message box a few seconds later. The shell closes when the messagebox is dismissed.

It seems to me that the 'else' caters to a non-existent or impossible use case. PyShell has several 'from idlelib.X import Y' statements. If those work, then "from idlelib import run' must work, and so too must the function equivalent.

[BreamoreBoy]

@terry just a reminder for yourself and your band of merry men and women.

[terryjreedy]

The problem with touching this stuff is that there is not only not an automatec test, there is not even a script for a manual test.

[terryjreedy]

Since filing this, I have decided that starting Idle directly with PyShell should be deprecated. That would affect any patch for this. In the meanwhile, there are other priorities.

[terryjreedy]

In bpo-36429, the 'else' branch that did not work was deleted.

The reason __import__ is discouraged is the reason for the repetition of 'run', in the line kept, as explained above. However, since the line works, it is not a bug, and I now prefer to leave it alone. If someone disables it, IDLE will not start.

del_exitf was added for Visual IDLE -- VIDLE (sp?) Investigating whether it is still needed and possible deleting it is another issue. So is deprecating starting with PyShell, or having pyshell as main running tests in a development setting.