The idlelib xyz.py filenames (about 60) are a collectively a mess.  There are about 6 different styles. I would like to *eventually* change all to short, lowercase, PEP-8 names, but the reasons have nothing to do with test names (which intentionally look to the future).

1. The variety of styles and length of some makes some hard to learn and remember. This discourages new people from working on Idle code.  After years, I still find some a problem. For this purpose, the patch does not go far enough.  Merely changing 'X' to '_x' does not make a long, multi word or word pieces name into a short, one-word name.  For examples: config_section_name_dialog.py and dyn_option_menu_widget.py are not where I want to end up.

2. Having a module and a class with the same name is confusing. Consider 'EditorWindow'.  In text, having to disambiguate by appending 'module' or 'class' is a nuisance.  In code, even that is not possible.  One must jump up to the top of a file to see if the import is 'import EditorWindow' or 'from EditorWindow import EditorWindow'.

3. A deeper reason I want name changes to be possible is that I would also like to be able to do some package-level refactoring.  60 files is already a lot and we may need more.  I think AutoComplete.py and AutoCompleteWindow.py should be combined into completions.py.  I would combine CallTips.py and CallTipWindow.py (I had to look to be sure it was not CallTipsWindow.py) into calltips.py.

In the other hand, PyShell.py has startup code (which I think might better be in a separate startup.py), some code for debugger and editor windows, and finally shell window code. I think the confusing Window class hierarchy should be redone, which would also mean some file reshuffling and renaming.

4. PEP434 suggested that a few generally useful, non-Idle specific files might be moved to the tkinter package.  This would also be a name change.


One problem with name changes is continued support for 2.7, which was originally scheduled to end about now.  If it were not for that, it would more easily be possible to introduce new names in some 3.x.0, possible after deprecation warnings.

Another barrier is the unknown usage by extensions of parts of idlelib 
beyond the narrow interface defined in extend.txt: an EditorWindow instance with Test, IOBinding, and FileList instances.

Summary: I agree with the goal.  But I have to reject the current patch because a) the change will have to be a process, not a single patch, and b) I do not agree with many of the new names.