[Idle-dev] Re-imagining Idle, Killer App

Terry Reedy tjreedy at udel.edu
Mon Apr 6 00:28:35 CEST 2015


 >> I have more concrete ideas on the wiki:
 >> https://github.com/asweigart/idle-reimagined/wiki

 > I will comment on specific ideas in further posts here.

Comments on the items on this page.
https://github.com/asweigart/idle-reimagined/wiki/Killer-App

1. Single dual pane window.  I proposed this on this list some time ago. 
  For a wide screen, I want side-by-side, as with turtledemo.  This 
could be user selectable.  (In fact, I would like 3 panes.) The work I 
did with Lita Cho on
   https://bugs.python.org/issue21597
   Allow turtledemo code pane to get wider.
to discover how to make moving the sash, the divider between panes, work 
well enough on all systems will be directly applicable to Idle.

This and the below are a major changes that I am not sure if I would 
want to backport to 2.7.

2. Tabbed file editor.  Already on the tracker. needs to be added.
   https://bugs.python.org/issue9262
   IDLE: Use tabbed shell and edit windows
There is no reason particular reason to limit the tabs to editor 
windows.  I would put all open windows on a tab instead of the taskbar. 
  I would also use tabs with every pane.

A separate idea that impinges on this one.  There are two good reasons 
to at least have the option of having a separate shell and user process 
for each editor window.  First, running a file in the editor currently 
wipes out everything you have done in an exploratory session in the 
shell, like it or not, and sometimes this is a real nuisance.  Second, 
editor completions and tool tips work best when the editor file has just 
been run, and can give wrong answers when another file has just been run.

3. Foreign language support.  A separate page and discussion, but 
someone has to do some actual work.

4. Autosave.  On the tracker, as noted.

5. Pip gui.  On the tracker, needs to be added.
   https://bugs.python.org/issue23551
   IDLE to provide menu options for using PIP

6. Paste code to x.  Separate page.  Not sure about this. Python-list 
and StackOverflow both want code pasted in questions and do NOT want 
soon-to-go-dead links.

7. Better tracebacks.  The short separate page has links to two pages 
with code but not examples.  I might like this, but need to see it in 
action.  The code would go in idlelib/run.py to enhance the traceback 
sent back to the idle shell process for display.  Enhanced traceback 
could be an option.  I suspect long trackbacks would be less of a 
nuisance when running code from the editor.

On python-list, I mentioned the idea of adding an 'undo output' feature 
that would put one back on the last statement entered, ready to edit. 
This would make long tracebacks less a nuisance in interactive entry also.

" When you get the "index out of range" error, Python should optionally 
tell you what the index value actually was." Message options are not 
practical.  Check the tracker for an existing issue and if the there is 
not one, open a request.

8. Error message explanation.  This seems similar to the idea I just 
posted.  I like the idea of having clicks on uneditable text pop up an 
explanation, instead of having to right click and select.

9. Version mismatch.  I am dubious about this.  Detection without 
running is really only feasible with a #! line, which I don't expect 
beginners to use.  'Python 2' and 'Python 3' each have multiple 
versions.  Using 'yield from' in 3.3 is just as bad as using it in 2.7.

10. Code checking.  There is a patch to run 3rd party checkers.
   https://bugs.python.org/issue21880
This is a follow up to the rejected idea of integrating pep8 
specifically (issue 18704, I just added 21880 as superceder).  As one 
can now for grep results, one would be able to jump from line numbered 
messages in the output window to lines in the editor.

Input at a >>> prompt is already syntax checked line by line.  However, 
I would prefer being allowed to edit the statement instead of getting a 
new prompt, as in
 >>> a a
SyntaxError: invalid syntax
 >>>
The message should be a beep and popup that goes away easily.

Editor code can be checked at any time with Alt-x, but this makes the 
shell the active window.  I want to change this.  Switching to the shell 
should not happen unless one want to run the code and the syntax is 
correct. Some checking of lines is already done in the editor for smart 
indenting.  I imagine we could add the same syntax check as done in the 
shell.

11. Tutorials. I have long thought about putting the Python tutorial in 
an enhanced read-only text window coupled with a shell and editor 
window.  Clicking on ">>> code" would load "code" into the shell at the 
current ">>> ".  Clicking on "example.py" would load example.py into an 
editor window.  This would work best with 1 and 2 implemented.

Designing for 3rd party tutorial creation, from the beginning, is a good 
idea.


Minor 1. Line numbers.  Already in process, as noted.

Minor 2. Detect disk changes and reload.  Notepad++ does this also, when 
the window is activated, except that reloading is optional, not 
automatic.  With that variation, I find this a useful feature.


Summary: We have had many similar ideas and agree on most of the new 
features you listed.  Many are already in progress at some stage or 
another.  I see them as logical enhancements of Idle, not as a replacement.

-- 
Terry Jan Reedy



More information about the IDLE-dev mailing list