Al Sweigart added the comment: Serhiy: I completely understand. My first instinct is to look at mass renamings and dismiss it as cosmetic changes for the sake of cosmetic changes. However, there are several problems that this fix corrects:
1) It makes it obvious which identifiers are modules and which are classes: - AutoComplete.AutoComplete is a module and class with the same name, making them ambiguous. - Same for AutoCompleteWindow.AutoCompleteWindow. - Same for AutoExpand.AutoExpand. - Bindings.py is a module but there is also a Bindings member in the EditorWindow class. - Same for CallTips.CallTips having ambiguous module/class name. - Same for ClassBrowser.ClassBrowser. - Same for CodeContext.CodeContext. - Same for ColorDelegator.ColorDelegator - But not the same for configDialog.ConfigDialog. - Same for Debugger.Debugger - Same for Delegator.Delegator - Same for EditorWindow (this is a big one, where the ambiguious use is in several files) - Same for FileList.FileList - Same for FormatParagraph.FormatParagraph - Same for HyperParser.HyperParser - Same for IOBinding.IOBinding - Same for MultiCall.MultiCallCreator's inner class, MultiCall. - Same for MultiStatusBar.MultiStatusBar - Same for OutputWindow, ParenMatch, PathBrowser, Percolator, PyShell, ReplaceDialog, RstripExtension, ScriptBinding, ScrolledList, SearchDialog, SearchDialogBase, SearchEngine, ToolTip, UndoDelegator, WidgetRedirector, WindowList, ZoomHeight - There is a StackViewer.py module and a StackViewer class, except the class is in Debugger.py This isn't a trivial, "just remember it works like this in one or two places" kind of technical debt. 2) These ambiguous names can be mitigated with "from x import *" statements; always use "from idlelib.AutoExpand import AutoExpand" and you can always assume "AutoExpand" refers to the class, not the module. But the codebase doesn't consistently do that. There is "from idlelib.AutoExpand import AutoExpand" but also "from idlelib import Debugger" (so in that file, Debugger refers to the module while Debugger.Debugger refers to the class). 2) It puts idle_test names in sync with the files they test. Currently there is a test_config_name.py but there is no config_name.py or configName.py file. (It tests configSectionNameDialog.py) 3) Any extensions that break due to these changes can be fixed in one line: import new_name as OldName I agree that large changes are error prone. In this case, that's partly because names are confusing and ambiguous, which is precisely what this change tries to mitigate. I really beg folks to not dismiss this change out of hand. These readability issues are death-by-a-thousand-paper-cuts. I think we should address this technical debt, not actively preserve it. IDLE dev is at a standstill, with the bulk of it resting on the efforts of a handful of people. Getting it into a better state can invite more contributors (I can personally name some people who would want to become involved with IDLE but are intimidated by labyrinthine codebases.) I volunteer to test any extension people can name for compatibility issues with this change. (Where should I start? IDLEX? The https://wiki.python.org/moin/IDLEextensions also lists lwickjr. Are there any others?) All the unit tests pass after these changes, which is something at least. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24225> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
