Serhiy, and anyone else: I am *painfully* aware that any change to idlelib could break 3rd party imports.  Efforts to improve IDLE have been crippled by the restriction of not doing so for years. But idlelib exists to implement IDLE and change is necessary to modernize IDLE.

In June/July 2010, after KBK left IDLE development, there was a long pydev discussion (50-100? posts) based on agreement that IDLE was somewhat old and crusty.  The question was whether to removed it from the stdlib or modernize it.  The latter meant: use ttk widgets, more to a modern single window, multi-pane, multi-tab design, and (I am sure) modernize the code.  As a Python user on Windows, I urged keeping IDLE.  The response, and the end of the discussion, were decisions to a) keep IDLE, at least for awhile, and b) to hand me commit privileges so I could try to help modernize IDLE.

I subsequently added 'a comprehensive test suite' as part of 'modernize'.  With GSOC student help, a start has been made.  What have not been added -- yet -- are tests that require refactoring and api changes -- because such changes could possibly break some person's use of the module.  I am no longer willing to apply significant patches without being able to freely write needed tests.

In February 2013, I helped write PEP 434, which mostly formalized points that were more or less informally true before.  One is the purpose of idlelib.  Another is that idlelib should be regarded as private in that it should be allowed to change, and even break 3rd party use (sometime in the undefined future) as needed to improve IDLE.

[Insert first 4 paragraphs and other bits of #26993, as well as the posts on this issue from a year ago.]

Why this patch, now.  1. a consistent set of PEP 8 module names, distinct from class names, is already beneficial to me.  Also see Al's and my comments above.  Note that Al independently came to the same conclusion as I after writing a few IDLE patches.  Others who have worked with the code have said the same.  2. Consolidation and splitting of files will require new names anyway.  3.  Even if we kept the current nasty hodgepodge of naming styles, I expect that changes withing files would eventually break most 3rd party imports anyway.  4. I think it better to break 3rd party imports all at once, in an early alpha release, than haphazardly over the course of 3.6 releases.