homepage

In msg243635 of the renaming issue #24225, Nick suggested
"One path you may want to consider is progressively factoring out a public "idlelib.extensions" API, and treat everything else in idlelib as fair game for renaming. Folks tend to be more tolerant of disruption if the new state of affairs is also clearly better for them, not just the folks making the change."
This issue is an implementation of that idea, except that I want to reserve 'extension' for modules added by 3rd parties using the extension interface. The new module would consist of callables that make builtin IDLE features available to non-IDLE tkinter code.
The first callable would replace the following from turtledemo.__main__
from idlelib.colorizer import ColorDelegator, color_config
from idlelib.percolator import Percolator
...
 Percolator(self.text).insertfilter(ColorDelegator())
...
 color_config(text)
with
from idlelib.interface import colorize
...
 colorize(text)
At the moment, interface would have the imports and 
def colorize(text):
 color_config(text)
 Percolator(self.text).insertfilter(ColorDelegator())
Future enhancements might be to accept a color scheme name and to return the Percolator instance (or a wrapper thereof), but these would not break code. In any case, colorize would be re-written if the needed incantation changed, and turtledemo would continue to work without change.
An new public module should not be backported for the usual reasons. New callables should also not be added except in comments. I plan to only add features that are requested, and perhaps a very few others, rather than everything and everything possible.

Import should fail if tk.TkVersion < 8.5.

Nick later suggested against this, and in the absence of requests, I don't want to do this, at least not before 3.7, if ever. What if we make a change that makes the public promise awkward? The docstring for colordelegator should say how it is used (in IDLE and turtledemo). Anyone else interested could follow the instructions, at their own risk, not mine.