Author terry.reedy
Recipients Al.Sweigart, kbk, ncoghlan, roger.serwy, serhiy.storchaka, terry.reedy
Date 2015-05-19.20:08:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Nick, as PEP 434 approver, I would like your comments on this issue.

The pep says that other than the startup modules, "the modules are undocumented and effectively private implementations."  It also says that the documented extension API should be respected but is vague about the extent to which the existence of extensions should otherwise be reasons to block changes to idlelib.

While this issue is about module names, changes to names and behavior within modules could also break extensions. We have in fact made such changes without worring about this.

Fedora 22 replaced yum with dnf as its package managater.  Accordig to
one of the reasons is problems with extensions. "Yum plugins are using any method from Yum code base thus any change there would cause the sudden crash of the Yum utility."  (What yum and idlelib have is common is mostly being undocumented.)  In a comment, the author summed up my feelings with respect to idlelib: "It really hard to maintain a project where you can’t change anything."

An example is #24199. I want to remove a zombie module, idlever.  Can I?  At least for 2.7 and 3.4, I think I will add a deprecation warning.

If we rename and refactor modules for 3.6, I would propose to add stub files to 2.7 and 3.5 with imports and a deprecation warning.  A combined completions module, for example, would get two stub files.  (An alternative for 2.7 could be to fix the worst bugs, declare Idle 2.7 frozen, and stop backporting.)

During the PEP 434 discussion, some core developers said that they would like to drop Idle completely.  This would break extensions much more thoroughly than changes proposed here.

Al: some research into extension practices would be helpful.  But keep in mind that idlex is much more than a set of extension modules. I believe it adds its own ui. 

Al: the current discrepancies between module and test names are intentional. The 'controversy' is entirely about idlelib, hence the title change.  When idlelib modules get 'nice' names, test names can be changed to match.
Date User Action Args
2015-05-19 20:08:32terry.reedysetrecipients: + terry.reedy, kbk, ncoghlan, roger.serwy, Al.Sweigart, serhiy.storchaka
2015-05-19 20:08:32terry.reedysetmessageid: <>
2015-05-19 20:08:32terry.reedylinkissue24225 messages
2015-05-19 20:08:31terry.reedycreate