Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idlelib: changing file names #68413

Closed
AlSweigart mannequin opened this issue May 18, 2015 · 34 comments
Closed

Idlelib: changing file names #68413

AlSweigart mannequin opened this issue May 18, 2015 · 34 comments
Assignees
Labels
topic-IDLE type-feature A feature request or enhancement

Comments

@AlSweigart
Copy link
Mannequin

AlSweigart mannequin commented May 18, 2015

BPO 24225
Nosy @terryjreedy, @kbkaiser, @ncoghlan, @ned-deily, @serwy, @roseman, @serhiy-storchaka
Files
  • idle_renaming.patch
  • idletest_renaming.patch
  • idle_updating_imports.patch
  • @newnames.txt
  • i3rename.bat
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/terryjreedy'
    closed_at = <Date 2016-06-01.00:24:38.914>
    created_at = <Date 2015-05-18.07:36:27.540>
    labels = ['expert-IDLE', 'type-feature']
    title = 'Idlelib: changing file names'
    updated_at = <Date 2016-06-04.05:20:28.435>
    user = 'https://bugs.python.org/AlSweigart'

    bugs.python.org fields:

    activity = <Date 2016-06-04.05:20:28.435>
    actor = 'ned.deily'
    assignee = 'terry.reedy'
    closed = True
    closed_date = <Date 2016-06-01.00:24:38.914>
    closer = 'terry.reedy'
    components = ['IDLE']
    creation = <Date 2015-05-18.07:36:27.540>
    creator = 'Al.Sweigart'
    dependencies = []
    files = ['39427', '39428', '39429', '42678', '42951']
    hgrepos = []
    issue_num = 24225
    keywords = ['patch']
    message_count = 34.0
    messages = ['243464', '243570', '243571', '243572', '243573', '243612', '243613', '243622', '243623', '243635', '250451', '264620', '264622', '264623', '264625', '265255', '265545', '265585', '266116', '266213', '266215', '266220', '266392', '266395', '266409', '266412', '266571', '266572', '266573', '266792', '266794', '267211', '267229', '267232']
    nosy_count = 9.0
    nosy_names = ['terry.reedy', 'kbk', 'ncoghlan', 'ned.deily', 'roger.serwy', 'markroseman', 'python-dev', 'Al.Sweigart', 'serhiy.storchaka']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue24225'
    versions = ['Python 3.6']

    @AlSweigart
    Copy link
    Mannequin Author

    AlSweigart mannequin commented May 18, 2015

    From the idlelib/idle_test/README.txt file:

    "The idle_test subdirectory should contain a test_xyz.py for each, where 'xyz' is lowercased even if xyz.py is not."

    However, this means the test file names are inconsistent with the scripts they test. Of the 20 test_*.py files, all 20 are inconsistent. Some of the test filenames don't even match the file, such as test_config_name.py which tests configSectionNameDialog.py.

    Since the original filenames aren't lowercase like the rest of the standard library, it would be better to rename them rather than renaming the test files: AutoComplete.py to autocomplete.py, ColorDelegator.py to colordelegator.py, etc. This is a find-and-replace change. Any shorter, better names for modules can also be made at this time.

    @AlSweigart AlSweigart mannequin added the topic-IDLE label May 18, 2015
    @AlSweigart
    Copy link
    Mannequin Author

    AlSweigart mannequin commented May 19, 2015

    The idle_renaming.patch file is for the file renamings under idlelib

    The idletest_renaming.patch file is for the file renamings under idlelib/idle_test

    The idle_updating_imports.patch file is for the content updates (mostly for import statements) due to the renamings.

    The unit tests all pass with these changes.

    @AlSweigart AlSweigart mannequin added the type-feature A feature request or enhancement label May 19, 2015
    @AlSweigart
    Copy link
    Mannequin Author

    AlSweigart mannequin commented May 19, 2015

    (I can reformat these patch files if that helps.)

    @AlSweigart
    Copy link
    Mannequin Author

    AlSweigart mannequin commented May 19, 2015

    For reference, here's all the files and their new filenames:

    aboutDialog.py about_dialog.py
    AutoComplete.py autocomplete.py
    AutoCompleteWindow.py autocomplete_window.py
    AutoExpand.py autoexpand.py
    Bindings.py bindings.py
    CallTips.py calltips.py
    CallTipWindow.py calltip_window.py
    ClassBrowser.py class_browser.py
    CodeContext.py code_context.py
    ColorDelegator.py color_delegator.py
    configDialog.py config_dialog.py
    configHandler.py config_handler.py
    configHelpSourceEdit.py config_help_source_edit.py
    configSectionNameDialog.py config_section_name_dialog.py
    Debugger.py debugger.py
    Delegator.py delegator.py
    dynOptionMenuWidget.py dyn_option_menu_widget.py
    EditorWindow.py editor_window.py
    FileList.py file_list.py
    FormatParagraph.py format_paragraph.py
    GrepDialog.py grep_dialog.py
    HyperParser.py hyper_parser.py
    IdleHistory.py idle_history.py
    idlever.py idle_ver.py
    IOBinding.py io_binding.py
    keybindingDialog.py keybinding_dialog.py
    macosxSupport.py mac_osx_support.py
    MultiCall.py multi_call.py
    MultiStatusBar.py multi_status_bar.py
    ObjectBrowser.py object_browser.py
    OutputWindow.py output_window.py
    ParenMatch.py paren_match.py
    PathBrowser.py path_browser.py
    Percolator.py percolator.py
    PyParse.py pyparse.py
    PyShell.py pyshell.py
    RemoteDebugger.py remote_debugger.py
    RemoteObjectBrowser.py remote_object_browser.py
    ReplaceDialog.py replace_dialog.py
    RstripExtension.py rstrip_extension.py
    ScriptBinding.py script_binding.py
    ScrolledList.py scrolled_list.py
    SearchDialog.py search_dialog.py
    SearchDialogBase.py search_dialog_base.py
    SearchEngine.py search_engine.py
    StackViewer.py stack_viewer.py
    tabbedpages.py tabbed_pages.py
    textView.py text_view.py
    ToolTip.py tool_tip.py
    TreeWidget.py tree_widget.py
    UndoDelegator.py undo_delegator.py
    WidgetRedirector.py widget_redirector.py
    WindowList.py window_list.py
    ZoomHeight.py zoom_height.py
    test_config_name.py test_config_section_name_dialog.py
    test_configdialog.py test_config_dialog.py
    test_formatparagraph.py test_format_paragraph.py
    test_grep.py test_grep_dialog.py
    test_hyperparser.py test_hyper_parser.py
    test_idlehistory.py test_idle_history.py
    test_parenmatch.py test_paren_match.py
    test_pathbrowser.py test_path_browser.py
    test_rstrip.py test_rstrip_extension.py
    test_searchdialogbase.py test_search_dialog_base.py
    test_textview.py test_text_view.py
    test_searchengine.py test_search_engine.py
    test_widgetredir.py test_widget_redirector.py

    @serhiy-storchaka
    Copy link
    Member

    Usually we avoid such mass renamings. This is errorprone and can break third-party plugins or even applications that use parts of IDLE. It also will made much harder to transfer patches between versions. I'm -1 for this proposition.

    @AlSweigart
    Copy link
    Mannequin Author

    AlSweigart mannequin commented May 19, 2015

    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.

    1. 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).

    1. 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)

    2. 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.

    @terryjreedy
    Copy link
    Member

    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.

    1. PEP-434 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.

    @terryjreedy
    Copy link
    Member

    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
    http://dnf.baseurl.org/2015/05/11/yum-is-dead-long-live-dnf/
    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 bpo-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.

    @terryjreedy terryjreedy changed the title IDLE test filenames don't match script filenames. Idlelib: changing file names May 19, 2015
    @terryjreedy
    Copy link
    Member

    Al, I meant to add that msg243612 better expresses the proper rationale for disruptive changes: making it easier for people (newcomers and this no-longer-newcomer) to learn idlelib, fix bugs, and make improvements

    @ncoghlan
    Copy link
    Contributor

    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.

    In terms of supporting legacy module names without retaining all that complexity in the main source code, I'd suggest looking into the way the "six.moves" module works.

    @terryjreedy
    Copy link
    Member

    A new factor has entered the picture: the opportunity to move dialogs from using tk widgets to ttk widgets. However, we cannot yet drop support for systems that do not have ttk widgets. We could accommodate using both sets of dialog widgets by adding lots of conditional code within each file as needed, but that would only solve the ttk or not issue.

    I decided instead to have separate files. This way, the ttk files can have PEP-8 names and style and refactorings. New files will be declared private in docstrings. When a new file is written, corresponding old files, if imported (by an extension or non-idle program) when ttk *is* being used , will raise a Deprecation Warning. The same idea will be used for the text window files for shell, edit, and output, which badly need refactoring both as they are and to allow tabbed windows with multiple files.

    Overall, the plan is to gradually add new files to all current versions (except, probably, 3.4) and delete old files in the future (possibly in 3.6, but not decided now). The transition overlap will be messier than a simple rename, but will avoid the problems of patch merges and immediately breaking 3rd-party code. And the result will be much more and much better than a simple rename.

    @terryjreedy terryjreedy self-assigned this Sep 11, 2015
    @terryjreedy
    Copy link
    Member

    Since I posted the message above, I have decided that there should be a new version of every currently used idlelib .py file and that all additions, with new names of course, should be done at once, but only to 3.5 and 3.6. I will soon open a new issue to explain why and post the number here.

    To prepare the patch for the new issue, I will try to use file idle_updating_imports.patch after replacing some of the new names with ones I prefer. The attached @newnames.txt is the list from msg243572 with the addition of the new names I currently favor. Some notes:

    1. idlever.py and ToolTip.py are not currently used, and will be deleted from the patch.

    2. help.py is new in 3.5.1 and currently only has the help viewer. It starts by declaring itself subject to change. I plan to move all other help menu code into this file and want to keep the name for the new file. I plan to rename the current file 'helpviewer.py' and change the imports in EditorWindow.py and macosxSupport.py accordingly

    3. Most of the changes I made were to delete underscores that Al inserted. They are not usually used in module names, even when they might be otherwise (example: tkinter.scrolledtext).

    4. Other changes should make related files easier to find.

    5. Some new names will disappear when files are combined.

    Any further discussion here should be limited to the new names.

    @terryjreedy
    Copy link
    Member

    Uploading slightly revised version.

    @serhiy-storchaka
    Copy link
    Member

    I don't think that simple renaming will give us any benefits, but if that will be made, please don't forgot to use the "hg mv" command for this for keeping the history. And please rename 2.7 files too, otherwise the backporting changes will be turned in hell.

    @terryjreedy
    Copy link
    Member

    For back compatibility reasons, I rejected a 'simple renaming', much as I would like to do it for reasons already given, and closed *this* issue in msg250451. As I said then here and elsewhere, I instead propose to add new files with new names. As I said above, I will propose a specific, revised plan in a new issue that I will open after some sleep. Please wait for that to discuss anything other than specific new names.

    @terryjreedy
    Copy link
    Member

    Alternate proposal is bpo-26993.

    @terryjreedy
    Copy link
    Member

    The conclusion of bpo-26993 is that we should apply this issue to 3.6. My target for inclusion is alpha2, scheduled for June 12.

    I am aware that this will require changing file names in existing patches on the tracker. But they nearly all have the much larger problem of needing the new tests that I will now start to require.

    Nick suggested above that breaking code should be more palatable if introduced in a context of overall improvement, including better clarity in supported APIs. Here is a start on the IDLE What's New entry that should be part of this issue.

    "Idlelib is being revamped to make IDLE look better and work better and to make it easier to maintain and improve IDLE.

    Part of looking better is the use of ttk widgets. As a result, IDLE no longer runs with tcl/tk 8.4. It now requires tcl/tk 8.5 or 8.6. We recommend running the latest release of either.

    'Revamping' includes renaming, refactoring, and consolidation of idlelib modules. As a result, imports of idlelib files that worked in 3.5 will usually not work in 3.6. At least a module name change will be needed, sometimes more. Information will be added to idlelib. In compensation, the eventual result with be that some idlelib classes will be easier to use, with better APIs and docstrings explaining them."

    @terryjreedy
    Copy link
    Member

    turtledemo.__main__ imports from idlelib will also need fixing.

    @terryjreedy
    Copy link
    Member

    Attached are my current renames, with just a few changes from before Most are lower case versions of the current names, perhaps shortened. I expect names with '_' to disappear in future file merges. I may change 'outwin' before 3.6 is released.

    The biggest changes are the 3 xyzBindings files. In tk, bind methods connect an event to an event handler. Bindings.py defines the menu of the main windows, and the associated pseudoevents, but not the event bindings. Hence, 'mainmenu'. (I considered just 'menu', but 'menu' is used as a local name in multiple places.) The other two may have bindings, but that is a fairly trivial implementatin detail and I would rather have name that reflect what the files do or implement. If 'iomenu' is expanded to implement more of the file menu, I may rename it 'filemenu' or 'files'.

    I have an independent clone of 3.6 with no connection to my normal working repositories. We can discuss squashing commits or not when I am ready to push.

    Al's 'idle_updating_imports.patch' missed a couple of renames in comments, but its code changes seem complete and correct as of a year ago. (The main change is replacing some code with the new help.py.) It will be very useful. I replaced his new names with mine with a short program and expect only a couple of chunks to fail.

    @terryjreedy
    Copy link
    Member

    I have privately committed 3 patches. Patch 1 is a renaming patch equivalent to Al's 2 renaming patches. Patch 2 updates filesnames within code, equivalent to Al's third patch. At this point, 'python -m test.test_idle' ran with all 188 test_methods passing. (I added several more test files last week.) IDLE started, but loading of the 9 extension files failed, entries with old names in .idlerc/config-extensions.cfg caused warning messages. The htests more or less work.

    Patch 3 results in IDLE starting without warnings and with all extensions loaded. It a) updated the file names in config-extensions.def. It b) added '<newname> = <oldname>', for example 'runscript = ScriptBinding', where 'ScriptBinding' is still the name of the class defined in the file, to meet the extension requirement that extension files have a callable entry point with the same name as the file.

    It also c) temporarily blocks reading from and writing to .idlerc/config-extensions.cfg. Reading old file names in existing customizations results in failed imports. This could be fixed in 3.6 by filtering old names, but there would still be the problem that writing customizations with new names would result in failed import warnings in all older versions, and we cannot patch existing releases. This is another example of how all-version config files are fragile to change.

    At this point, IDLE starts normally, with no warnings. I will retry the htests, work through the menus, and test the shell and editor windows, looking for other name related problems. Once this is done, and any fixes made, this issue will be complete, and I would like to push the three or four patches.

    Ned, do you want me to post the patches first?

    I will open another issue about turning extensions into normal code, so config-extensions will only be for external extensions. Then config-extensions.cfg can be read (with filtering) and written (but there will be nothing to write without added extensions).

    @terryjreedy
    Copy link
    Member

    'De-extensionizing' issue is bpo-27099.

    @ned-deily
    Copy link
    Member

    Ned, do you want me to post the patches first?

    Terry, at this stage of the release cycle, I think that's up to you and whether you want someone to do a code review prior to pushing upstream. Since this sounds like a fairly major change, though, it might be the prudent thing to do. I would be happy to take a quick look at the patches myself but I'm not in a position to do a detailed review of IDLE code; hopefully, others more familiar with it would be.

    @terryjreedy
    Copy link
    Member

    Ned, the rename (only) patch is useless to read as it is hg's bloated expansion of the rename commands in i3rename.bat.

    The main update is based on my review of Al's patch. In user testing, I discovered that the debugger depended on 'RemoteDebugger.py' being prefix + 'Debugger.py', so that its code needed more than a simple name replacement when I changed to 'debugger.py' and 'debugger_r.py'. We both missed "from idlelib import PathBrowser" buried in EditorWindow.open_path_browser. I plan to collapse the update patches after I finish live user testing. I am now using patched IDLE for further editing.

    @terryjreedy
    Copy link
    Member

    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 bpo-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.

    @ncoghlan
    Copy link
    Contributor

    To add to Terry's points: folks that would like to keep using the idlelib APIs as they exist in Python 3.5 will be free to create an idlelib35 project on PyPI, and bundle that or depend on it, depending on how their application manages dependencies.

    @terryjreedy
    Copy link
    Member

    The only external uses I know of currently are the imports of percolator/colorizer and textview in turtledemo. There is currently a coloring glitch in 3.5 which continues in 3.6 after the renames. See bpo-27117. I won't be surprised if making the colorizer easier to test (by adding an option to explicity pass a color scheme, for instance) makes it easier to use.

    I will keep other uses in mind if informed about them.

    My careful use tests also pinned down an existing and bizarre glitch in tkinter.simpledialog, reported in bpo-27115.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented May 28, 2016

    New changeset 6ecd4db71b88 by Terry Jan Reedy in branch 'default':
    Issue bpo-24225: Rename many idlelib/.py and idlelib/idle_test/test_.py files.
    https://hg.python.org/cpython/rev/6ecd4db71b88

    New changeset 0c3fdb161901 by Terry Jan Reedy in branch 'default':
    Issue bpo-24225: Within idlelib files, update idlelib module names.
    https://hg.python.org/cpython/rev/0c3fdb161901

    @terryjreedy
    Copy link
    Member

    Revision should definitely be tested on Mac by running IDLE from a console to check for any Mac-specific warnings and check that the menu looks 'right', which is to say, same as with 3.5.

    Still to do: news entries, What's New section, README.txt revision with new names.

    @terryjreedy
    Copy link
    Member

    I have a new idea for public interfaces: keep most of idlelib private and add a new 'interface' module containing public interfaces. It could be backported to 3.5 and even 2.7.

    This was prompted by working with turtledemo. It currently imports textview, percolator, and colorizer to create a colorized code viewer. At the moment, changing the names in the three imports worked, but that could change if any of the files are refactored. (And what about people who have trouble hooking the three components together correctly?)

    Instead, lets create, say, class ColorCodeview (or maybe a function) in interface and have turtledemo do one import, say 'from idlelib.interface import ColorCodeview'. The internal code code would be slilghtly different in each of 2.7, 3.5, and 3.6 (and maybe different again sometime after the initial commit). But the import and basic use should be the same.

    The only thing I might put in the main idlelib doc would be something like 'See the interface module for currently supported external uses of idlelib components."

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jun 1, 2016

    New changeset 20bd4c23cfe4 by Terry Jan Reedy in branch 'default':
    Issue bpo-24225: Update idlelib.README.txt with new file names and event handlers.
    https://hg.python.org/cpython/rev/20bd4c23cfe4

    @terryjreedy
    Copy link
    Member

    I brought IDLE news entries up to date 2 days ago. This patch updates README.txt with the new names and many new entries for event handlers. A What's New entry needs to wait for more patches, and is the subject of bpo-27163. This completes the 'still to do' list in msg266572.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jun 4, 2016

    New changeset 5dcc52d6829f by Ned Deily in branch 'default':
    Issue bpo-24225: Fix additional renamed module references.
    https://hg.python.org/cpython/rev/5dcc52d6829f

    @terryjreedy
    Copy link
    Member

    Thanks. Did you grep the whole repository for 'idlelib' or did you think to look for the latter two?

    @ned-deily
    Copy link
    Member

    I just tried to run IDLE from the command line as a (UNIX) user would. And then I grepped. :)

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    topic-IDLE type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants