deprecate importing components of IDLE

[roseman]

BPO	24861
Nosy	@terryjreedy, @kbkaiser, @serwy, @roseman

^{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 2015-09-21.05:50:59.610>
created_at = <Date 2015-08-13.21:11:49.904>
labels = ['expert-IDLE', 'type-feature']
title = 'deprecate importing components of IDLE'
updated_at = <Date 2015-09-21.23:36:12.376>
user = 'https://github.com/roseman'

bugs.python.org fields:

activity = <Date 2015-09-21.23:36:12.376>
actor = 'python-dev'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2015-09-21.05:50:59.610>
closer = 'terry.reedy'
components = ['IDLE']
creation = <Date 2015-08-13.21:11:49.904>
creator = 'markroseman'
dependencies = []
files = []
hgrepos = []
issue_num = 24861
keywords = []
message_count = 5.0
messages = ['248540', '248546', '251202', '251204', '251280']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'kbk', 'roger.serwy', 'markroseman', 'python-dev', 'Al.Sweigart']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue24861'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5', 'Python 3.6']

[roseman]

One of the concerns with making significant structural changes to the IDLE codebase is breakage of external that might import a piece of idlelib (so not just 'import idlelib' but a particular submodule).

PEP-434 already makes the case that this behaviour is unsupported ("the modules are undocumented and effectively private implementations"). In the interests of not digging this particular hole any further, I'm suggesting we make this official.

I don't know what the appropriate mechanism would be (e.g. something in IDLE's README.txt file, something at the top of each IDLE module, etc.).

Based on some suggestions on idle-dev, I did some searching to find out what impact this might have. As expected, most uses import the whole thing, either documenting how to run IDLE, or launching it as an external editor. This is done as both "import idlelib" but also as "import idlelib.idle"

Turtledemo appears to be the only thing in stdlib that imports a piece of idlelib.

From nullege.com, one reference to a now-defunct wiki/collaboration tool called Springnote. From programcreek.com, nothing significant.

Multiple applications do import PyShell as a way of starting a Python shell in their application. Usually they do just call PyShell.main(). Sometimes though they do "reach inside" in fairly significant ways that might break if the code were substantially changed. For example, search for PyShell in http://igraph.org/python/doc/igraph.app.shell-pysrc.html

I could locate no other significant uses based on Google search, etc.

The one exception I would therefore suggest to the "no importing submodules" would be importing PyShell to open up a Python shell window. I'd go further to suggest that the existing PyShell be called something else, and a new PyShell wrapper be created which documents an official API (with therefore very limited mucking inside), and then delegates to an actual implementation.

[terryjreedy]

Thank you for doing the research. It seems that extensions are the only unknown. Steps for doing this.

1. Nick once said to start with a notice in idlelib.__init__. How about the following.

The idlelib package implements the Idle application, which include an interactive shell and editor. The files named idle.* should be used to start Idle. The other files are private implementations and should not be imported by other applications. Their details are subject to change. See PEP-434 for more informaton.

2. Put same in NEWS.txt -- not just a notice that a notice was added to .__init__, but the notice itself.

3. Put a single line at the top of each 'new' file. Perhaps

# Private implementation module. API subject to change.

4. 'Old' files, which will go away someday, perhaps as soon as 3.6, are less of a concern to me. If one that has been replaced by a ttk version is imported when use_ttk is true, we can assume that it is being imported by an extension and issue a DeprecationWarning.

5. PyShell is a special case since "from idlelib.PyShell import main; main()" (essentially the content of idlelib.__main__) was once advertised as the way to start Idle. PyShell is also a special case because it includes startup code, shell code, and editor debug code, making it a prime target for refactoring. If main() were moved elsewhere and __main__.py and idle.* files modified to point to the new location, we could raise a DeprecationWarning in PyShell.main before calling the new main.

[python-dev]

New changeset b7bbb2c1e1f9 by Terry Jan Reedy in branch '2.7':
Issue bpo-24861: Add docstring to idlelib.__init__ with 'private' warning.
https://hg.python.org/cpython/rev/b7bbb2c1e1f9

New changeset 084a8813f05f by Terry Jan Reedy in branch '3.4':
Issue bpo-24861: Add docstring to idlelib.__init__ with 'private' warning.
https://hg.python.org/cpython/rev/084a8813f05f

[terryjreedy]

Individual files will be handled in separate issues.

[python-dev]

New changeset e9edb95ca8b6 by Terry Jan Reedy in branch '2.7':
Issue bpo-24861: add Idle news items and correct previous errors.
https://hg.python.org/cpython/rev/e9edb95ca8b6

New changeset 5087ca9e6002 by Terry Jan Reedy in branch '3.4':
Issue bpo-24861: add Idle news item and correct previous errors.
https://hg.python.org/cpython/rev/5087ca9e6002