This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Idlelib: changing file names
Type: enhancement Stage: resolved
Components: IDLE Versions: Python 3.6
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: terry.reedy Nosy List: Al.Sweigart, kbk, markroseman, ncoghlan, ned.deily, python-dev, roger.serwy, serhiy.storchaka, terry.reedy
Priority: normal Keywords: patch

Created on 2015-05-18 07:36 by Al.Sweigart, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit
idle_renaming.patch Al.Sweigart, 2015-05-19 10:22 review
idletest_renaming.patch Al.Sweigart, 2015-05-19 10:23
idle_updating_imports.patch Al.Sweigart, 2015-05-19 10:23
@newnames.txt terry.reedy, 2016-05-02 05:39
i3rename.bat terry.reedy, 2016-05-22 23:06
Messages (34)
msg243464 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2015-05-18 07:36
From the idlelib/idle_test/README.txt file:

"The idle_test subdirectory should contain a for each, where 'xyz' is lowercased even if 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 which tests

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: to, to, etc. This is a find-and-replace change. Any shorter, better names for modules can also be made at this time.
msg243570 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2015-05-19 10:22
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.
msg243571 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2015-05-19 10:23
(I can reformat these patch files if that helps.)
msg243572 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2015-05-19 10:33
For reference, here's all the files and their new filenames:
msg243573 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-05-19 10:45
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.
msg243612 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2015-05-19 17:29
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.
- 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 module and a StackViewer class, except the class is in

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 but there is no or file. (It tests

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 also lists lwickjr. Are there any others?)

All the unit tests pass after these changes, which is something at least.
msg243613 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-05-19 17:54
The idlelib 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: and 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 and should be combined into  I would combine and (I had to look to be sure it was not into

In the other hand, has startup code (which I think might better be in a separate, 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.
msg243622 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-05-19 20:08
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.
msg243623 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-05-19 20:13
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
msg243635 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2015-05-19 23:35
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.
msg250451 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-09-11 05:35
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.
msg264620 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-02 05:28
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. and are not currently used, and will be deleted from the patch.

2. 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 '' and change the imports in and 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.
msg264622 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-02 05:39
Uploading slightly revised version.
msg264623 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-05-02 05:48
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.
msg264625 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-02 06:16
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.
msg265255 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-10 18:29
Alternate proposal is #26993.
msg265545 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-14 22:01
The conclusion of issue 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."
msg265585 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-15 06:18
turtledemo.__main__ imports from idlelib will also need fixing.
msg266116 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-22 23:06
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. 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 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.
msg266213 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-24 01:50
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).
msg266215 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-24 02:03
'De-extensionizing' issue is #27099.
msg266220 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-05-24 03:29
> 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.
msg266392 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-25 20:54
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 '' being prefix + '', so that its code needed more than a simple name replacement when I changed to '' and ''.  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.
msg266395 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-25 22:55
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.
msg266409 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2016-05-26 04:22
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.
msg266412 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-26 06:16
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 #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 #27115.
msg266571 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-05-28 19:53
New changeset 6ecd4db71b88 by Terry Jan Reedy in branch 'default':
Issue #24225: Rename many idlelib/*.py and idlelib/idle_test/test_*.py files.

New changeset 0c3fdb161901 by Terry Jan Reedy in branch 'default':
Issue #24225: Within idlelib files, update idlelib module names.
msg266572 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-28 20:25
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.
msg266573 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-28 20:30
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."
msg266792 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-06-01 00:18
New changeset 20bd4c23cfe4 by Terry Jan Reedy in branch 'default':
Issue # 24225: Update idlelib.README.txt with new file names and event handlers.
msg266794 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-06-01 00:24
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 #27163.  This completes the 'still to do' list in msg266572.
msg267211 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-06-04 00:51
New changeset 5dcc52d6829f by Ned Deily in branch 'default':
Issue #24225: Fix additional renamed module references.
msg267229 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-06-04 04:26
Thanks.  Did you grep the whole repository for 'idlelib' or did you think to look for the latter two?
msg267232 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-06-04 05:20
I just tried to run IDLE from the command line as a (UNIX) user would. And then I grepped. :)
Date User Action Args
2022-04-11 14:58:17adminsetgithub: 68413
2016-06-04 05:20:28ned.deilysetmessages: + msg267232
2016-06-04 04:26:31terry.reedysetmessages: + msg267229
2016-06-04 00:51:19python-devsetmessages: + msg267211
2016-06-01 00:24:38terry.reedysetstatus: open -> closed
resolution: fixed
messages: + msg266794

stage: needs patch -> resolved
2016-06-01 00:18:27python-devsetmessages: + msg266792
2016-05-28 20:30:50terry.reedysetmessages: + msg266573
2016-05-28 20:25:32terry.reedysetmessages: + msg266572
stage: test needed -> needs patch
2016-05-28 19:53:22python-devsetnosy: + python-dev
messages: + msg266571
2016-05-26 06:16:03terry.reedysetmessages: + msg266412
2016-05-26 04:22:08ncoghlansetmessages: + msg266409
2016-05-25 22:55:47terry.reedysetmessages: + msg266395
2016-05-25 20:54:23terry.reedysetmessages: + msg266392
2016-05-24 03:29:33ned.deilysetmessages: + msg266220
2016-05-24 02:04:11terry.reedylinkissue27099 dependencies
2016-05-24 02:03:28terry.reedysetmessages: + msg266215
2016-05-24 01:50:56terry.reedysetmessages: + msg266213
2016-05-22 23:06:39terry.reedysetfiles: + i3rename.bat

messages: + msg266116
2016-05-15 06:18:26terry.reedysetmessages: + msg265585
2016-05-14 22:09:05terry.reedylinkissue26993 superseder
2016-05-14 22:03:39terry.reedysetsuperseder: Idlelib: changing file names ->
2016-05-14 22:03:39terry.reedyunlinkissue24225 superseder
2016-05-14 22:03:21terry.reedysetsuperseder: Idlelib: changing file names
resolution: later -> (no value)
stage: test needed
2016-05-14 22:03:21terry.reedylinkissue24225 superseder
2016-05-14 22:01:06terry.reedysetnosy: + ned.deily

messages: + msg265545
versions: - Python 3.5
2016-05-10 18:29:10terry.reedysetmessages: + msg265255
versions: - Python 2.7
2016-05-02 06:16:47terry.reedysetmessages: + msg264625
2016-05-02 05:48:30serhiy.storchakasetstatus: closed -> open

messages: + msg264623
stage: resolved -> (no value)
2016-05-02 05:39:35terry.reedysetfiles: - @newnames.txt
2016-05-02 05:39:23terry.reedysetfiles: + @newnames.txt

messages: + msg264622
2016-05-02 05:28:05terry.reedysetfiles: + @newnames.txt

messages: + msg264620
2015-09-11 05:36:00terry.reedysetstatus: open -> closed
messages: + msg250451

assignee: terry.reedy
resolution: later
stage: resolved
2015-08-06 15:37:36markrosemansetnosy: + markroseman
2015-05-19 23:35:58ncoghlansetmessages: + msg243635
2015-05-19 20:13:33terry.reedysetmessages: + msg243623
2015-05-19 20:08:32terry.reedysetnosy: + ncoghlan
title: IDLE test filenames don't match script filenames. -> Idlelib: changing file names
messages: + msg243622

versions: + Python 2.7, Python 3.6
2015-05-19 17:54:11terry.reedysetmessages: + msg243613
2015-05-19 17:29:53Al.Sweigartsetmessages: + msg243612
2015-05-19 10:45:30serhiy.storchakasetnosy: + terry.reedy, kbk, roger.serwy, serhiy.storchaka
messages: + msg243573
2015-05-19 10:33:30Al.Sweigartsetmessages: + msg243572
2015-05-19 10:23:50Al.Sweigartsetfiles: + idle_updating_imports.patch

messages: + msg243571
2015-05-19 10:23:20Al.Sweigartsetfiles: + idletest_renaming.patch
2015-05-19 10:22:58Al.Sweigartsetfiles: + idle_renaming.patch
type: enhancement
messages: + msg243570

keywords: + patch
2015-05-18 07:36:27Al.Sweigartcreate