classification
Title: deprecate importing components of IDLE
Type: enhancement Stage: resolved
Components: IDLE Versions: Python 3.6, Python 3.4, Python 3.5, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: terry.reedy Nosy List: Al.Sweigart, kbk, markroseman, python-dev, roger.serwy, terry.reedy
Priority: high Keywords:

Created on 2015-08-13 21:11 by markroseman, last changed 2015-09-21 23:36 by python-dev. This issue is now closed.

Messages (5)
msg248540 - (view) Author: Mark Roseman (markroseman) * Date: 2015-08-13 21:11
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.
msg248546 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-08-14 00:16
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.
msg251202 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-09-21 05:44
New changeset b7bbb2c1e1f9 by Terry Jan Reedy in branch '2.7':
Issue #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 #24861: Add docstring to idlelib.__init__ with 'private' warning.
https://hg.python.org/cpython/rev/084a8813f05f
msg251204 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-09-21 05:50
Individual files will be handled in separate issues.
msg251280 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-09-21 23:36
New changeset e9edb95ca8b6 by Terry Jan Reedy in branch '2.7':
Issue #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 #24861: add Idle news item and correct previous errors.
https://hg.python.org/cpython/rev/5087ca9e6002
History
Date User Action Args
2015-09-21 23:36:12python-devsetmessages: + msg251280
2015-09-21 05:50:59terry.reedysetstatus: open -> closed
resolution: fixed
messages: + msg251204

stage: patch review -> resolved
2015-09-21 05:44:50python-devsetnosy: + python-dev
messages: + msg251202
2015-08-14 00:16:51terry.reedysetstage: patch review
2015-08-14 00:16:34terry.reedysetpriority: normal -> high
assignee: terry.reedy
messages: + msg248546

versions: + Python 2.7, Python 3.4
2015-08-13 21:11:49markrosemancreate