Idlelib needs a roadmap with a bit of history to help orient new contributors to IDLE as to where I see it going. I am not sure whether to add this to README.txt or make is a separate roadmap.txt file. A rough draft (which started as just an outline ;-):

Summary of planned improvements:
Fix bugs and selectively add enhancements.
Continue improving tests.
Modernize code and refactor as needed for other improvements.
Convert tk widgets with ttk equivalents to ttk.
Convert IDLE from multiple windows to a window with tabbed panes.

Recent history relevant to current improvements:

• Summer 2010: Pydev discussed whether to remove IDLE (too old) or modernize it. 'Modernize' mostly meant 'use the better-looking ttk widgets' and 'convert IDLE a modern single window app'. The decision was to modernize, but this was mostly blocked from starting at that time. Using ttk dependably requires tcl/tk 8.5. Reorganizing IDLE externally requires internal reorganization that will break 3rd party extensions that use more than the documented extension API.

• Winter 2013: PEP-434 formalized the practice of allowing IDLE improvements to be backported even if more of an enhancement than a bug fix. Except for idlelib.idle.*, it also declared idlelib to be a 'private implementation modules'. The intention was to eventually allow refactoring, even if not immediately. 'Big' changes like using ttk and tabbed pane conversion were specifically kept blocked until decided otherwise in further discussion.

• Spring 2016: After the required further discussion, which began the previous summer, modernization and refactoring were unblocked for IDLE 3.6+. IDLE 3.6 was allowed to (and now does) require tcl/tk 8.5. Any 3rd-party code that requires 3.5 idlelib can adjust, require Python 3.5, or incorporate 3.5 idlelib.

Specific goals for 3.7:

• Bug fixes: Some priorities are fix hangs and crashes; continue after exceptions, if possible, instead of exiting; display fatal exceptions in a tk messagebox before exiting. Backport all changes to 3.6.

• Unittests: Continue expanding the test/test_idle.py and idlelib/idle_test/ suite begun in Summer 2013. Change code as needed to enable testing. (The May 2016 decision allows this to be done freely.) Ideally, test every patch to prevent regressions.

• Dialog appearance and operation: Htests ensure that widget creation code runs and that the 'look and feel' is minimally acceptable. Convert any remaining 'sanity check' code not converted in summer 2014, such as in config.py. Fix some remaining consistency issues. Rework About IDLE and the option dialogs.

• Modernizing code: After the May 2016 decisions, modules were renamed to short lowercase PEP-8 names. Changes within modules are best done when adding tests (if a module is not already fully tested). Some specifics:

  • Convert function names to lowercase.
  • Replace '*' in 'from tkinter import *' with objects.
  • Convert tkinter submodule imports from the backwards-looking 2to3 conversion. Change 'import tkinter.font as TkFont' to 'from tkinter import font' and replace 'TkFont' with 'font' in the rest of a module. Do the same with messagebox, colorchooser, and simpledialog.
  • Eliminate unneeded intermediate collections objects (some from 2to3 conversion). Example: 'for k in list(d.keys):' should be 'for k in d:'.

[Notes: import * and VALUE versus 'value' are discussed in bpo-30290. Searching idlelib for 'import tkinter.' gets 16 hits.]

• Refactoring: Make Editor, PyShell, and Output subclasses of a base text-based window that only has common features. Separate startup code from pyshell.

• Ttk widgets: Some windows and dialogs have been converted. Finish. Optional: allow selection of available themes. [Futuristic: create an IDLE theme, possibly based on the Python snake colors, green, blue, and yellow.]

• Tabbed panes: Convert any listed toplevel windows with multiple widgets to windows with a frame with multiple widgets. (The help window was specifically designed this way.) Frames can later be moved from the window to a tab. (To do this, text-based frames in menu windows must also be disentangled from the menu.)

I would like to have a single window app by 2017, but that is too speculative to list now.

Roadmap definitely helps us for targeting what to do and clear the current development status. Such as bpo-27609 helps a lot for focus on improving on part of the IDLE.

1. Should this be merged with the existing TODO.txt to ROADMAP.txt?
2. What does a "single window app" mean, the current design isn't a "single window app"?

The existing todo.txt is a decade out of date or so. A low priority item is to review it against open issues + my own todo list. What I remember from when I read it is that some seemed either very low priority or something I don't really want to do. There are also XXX and TODO comments in some modules.

Single window app. Look at your browser. Open at least 10 pages in separate tabs. This might be IDLE in the future. Then imagine that each page was instead in a separate window. This is IDLE today. Find is also in a separate window. On older Windows, most separate windows is a separate icon on the task bar, though in Win 10, multiple windows are stacked under one icon. Or try the same experiment with a tabbed editor such as Notepad++. [Note that one can, for instance, have multiple windows, but each window usually has multiple tabs.]

Terry, how do you think about the roadmap? I have two component that I think it should be put on the roadmap.

1. the goto/search/replace dialog to single-window app (bpo-30521, bpo-27115)

From internal diagram (https://i.imgur.com/1WZwakQ.png) it seem to search/replace dialog share the same based, I think we can first start from here to make a single-window app. To discuss which kind of style that we may change in future. In bpo-30521, I propose to make it as vscode/sublime style, a top bar for goto with different label. And for search/replace a bottom dialog like vscode/sublime could be used.

2. lineno sidebar, and pyshell tab issue (bpo-30663, bpo-7676)

Another big problem (I think) in IDLE is the pyshell tab issue. It seem that is very conflict with PEP-8 when IDLE using tab in pyshell. In bpo-7676 you said that should be done with sidebar, In bpo-30663, I first propose lineno sidebar in edit window, if this is been accepted, then I think bpo-7676 may be solved by sidebar method used in lineno.

How do you think about this two issue?

I strongly agree with the idea of writing documents that describe a bit of history to help orient new contributors to IDLE as to where the involved contributors see it going.

As a new comer, before I started to trace the codes of idlelib. A question bothers me all the time. "Why do we need idlelib since there are so many brilliant IDEs out there?" And I'm not sure whether should I keep reading the codes or not.

So, I want to say Thank you to Terry. Your draft helped me.

I'm really happy to see this question had been discussed in summer 2010. And the result is to modernize idlelib.

However, I have a suggestion :)

Although the result of the discussion is to modernize. I suggest to add few lines to describe the reasons why this decision had been made. And references (if possible) are needed to provide since some readers might want to see the original discussion.

How do you think? :)

Attached is my current sorted list of IDLE issues. It is a detailed map as opposed to the overview I posted before.

I spent a couple of days last week reviewing issues, making sure that all IDLE issues were marked category IDLE and that all with a patch were on my list, where they are marked by * after the issue number. (Most everything else should be also.) After closing 24 issues, there were 220 left, 115 with a patch to review. I marked a few issues with ** for attention soon.

I obviously need help reviewing existing patches, and in some cases, turning them into github pull requests.

I still need to review and clean up the todos on the list. I want to review TODO.txt to see what should be added (and then replace that file with this, under a different name). There are also TODOs and XXXs in individual module files.

I posted a older version to idle-dev about Sept 2015 and will probably do so again.

A possible revision of the first paragraph of my opening message.

• Summer 2010: Pydev discussed whether to remove IDLE (too old) or to maintain and 'modernize' it. Included in the latter were use of the better-looking ttk widgets and of tabbed windows and panels in a single window app. Core developers decided to keep IDLE and encourage more maintenance. They approved in principle using ttk and other major changes in principle but did not immediately approve the necessary compatibility breaks.

KunYu: I wrote the roadmap draft to help two new contributors, and any the follow. I only gave as much history as I thought relevant to new contributors. In particular, IDLE development is exempt from two normal limitations: we can backport enhancements, and I am currently backporting all patches to 3.6; we can and are refactoring modules and changing their API (which requires changing calls in other modules). People should know that these are exceptions so that they don't propose the same for other modules. I should emphasize this more than I did before.

Louie: Question 1. I intend Roadmap.txt to be an overview of the main goals, each of which will require multiple patches (like 20 or more). The good ideas in TODO.txt that are not already implemented, issues, or items on my patch-oriented list should be added to my list.

Question 2. Currently, each window is limited to one hard-coded master frame, which has no independent existence as a separate class. What can one do with one window? In Shell, execute code entered by key or pasting. In Editor, edit and save code. To edit and run, one must have at least two windows. In contrast, modern browsers have multiple tabs with multiple panes. The original browsers, developed about the same time as tcl/tk, did not. (One can still choose to open each page in a separate window, or choose multiple windows each with multiple tabs.) Similarly, at least some modern editors also have multiple tabs. I use Notepad++ for text files and read-only code review because of this.

Terry: For question 1, I think we can mark out the value point of the part in your roadmap.txt which we have more priority to fixed first, then get a bi-weekly (maybe) sprint to fixed one part.

If you are suggesting that at least you, Cheryl, and I work together on one 'area' to make fairly rapid, visible, and satisfying progress, I am all for that. But rather than focus on one of the 5 types of improvements for all components, I would rather focus on multiple improvements of one component. I think configuration is a good place to start, as it has been a major source of user annoyance. That is why I and Cheryl have been working on configdialog and config_key, with some help from you, for the last week. I would like to continue.

The config module also needs attention. There are 4 issues, 3 with patches, that claim startup problems. What problems still exist and do the patches solve anything?

There are non-configuration issues blocked on the issue of where to put configuration options on config dialog.

At least some coordination should be on idle-dev. Have you subscribed yet?

Replace 'Relevant History' with the following;

Python and IDLE development policies:

• Dependence on tcl/tk: Except when security is involved, Python is slow to require upgrade of 3rd party dependencies. IDLE is mostly bound by this. In July 2010, core developers endorsed future use of ttk widgets. Serious discussion began in August 2015. In May 2016, it was decided to make tcl/tk 8.5 a requirement for running IDLE, and allow use of ttk widgets. IDLE cannot yet depend on 8.6 being present. (And so we keep both .gif (for 8.5) and .png (for 8.6+) versions of icons.)

• API changes: Python divides APIs into private -- freely changed -- and public -- slow to change, and only after public discussion and notice. In July 2010, core developers also endorsed future reorganization of IDLE, such as attaching editors to tabs rather than windows. But the status of idlelib APIs was then too ambiguous to do the needed refactoring needed. PEP-434, March 2013, declared most of idlelib to be a private implementation of IDLE. In May 2016, it was decided to start refactoring freely.

• Enhancements: Python classifies changes as bug-fixes, which can be applied to maintenance versions, or enhancements, which can only be applied to the upcoming development version. Except for the ttk and re-organization changes, PEP-434 formally exempted IDLE from the need to classify patches, allowing all to be backported. Currently, all patches are backported from 3.7 to 3.6.

Terry, thank for posting the list of all the IDLE issues. This is extremely helpful to me and I appreciate your effort in organizing it.

I'm also on board for working together on targetted areas. Without that, I was focusing on PEP-8, docstrings, linting, ttk conversion, and unit tests. But, as configdialog showed, even those require coordination with existing patches.

I can start turning the ** issues into pull requests too.

Hi Terry, Louie and Cheryl

I would like to work with you guys. :)

However, I still need some time to study the codes.

Now I am focusing on reading unit tests. By reading the tests, I can know how the code works and further to write tests that are necessary but yet to write.

Most of the patches lack tests, and writing them is a bottle neck. Reading the current one, in conjunction with the code and the unittest doc, is a good way to learn.

Terry: I'm on idle-dev, the bi-weekly sprint I said isn't only one time, I mean about each bi-weekly. I'm ok with concentrate on multiple improvements of one component.

Thanks Terry,

I'll focus on the current tests. Will catch up with you guys later. :D

My private idle-issues.txt is in the process of being superseded by a github project: IDLE issues. After I check that ideas here without issue are recorded there or on another isssue, I will close this.