[Idle-dev] Re-imagining Idle (was re; going to pycon

[Terry Reedy]

Rearranging in temporal order

On 3/31/2015 7:22 PM, Al Sweigart wrote:
 >  Douglas Blank <dblank at cs.brynmawr.edu> wrote:

I did not get the message from Douglas, only Al's quote.

 >> On Tue, March 31, 2015 4:54 pm, Al Sweigart wrote:

>>> I'm giving a keynote for the Python Education Summit to talk
>>> about the IDLE Reimagined project and changing IDLE to be more
>>> an education tool for beginners than a standard IDE for
>>> developers. It'd be great to bounce deas off of IDLE developers
>>> (or anyone who has ideas/critiques).

I am not going, but I have been thinking about Idle improvements for 
years. There are issues and code for several on the tracker.  The 
following are what I see as major problems in making enhancements.

1. Tests.  Without tests, whether automated unit tests or scripted 
manual tests (I and GSOC students have added some of both), it is too 
easy to introduce bugs when refactoring.

2. Bugs.  Does it make sense to refactor buggy code?  In any case, the 
existing startup bugs, when triggered, are especially baffling to beginners.

3. Ambiguous approval authority.  Years ago, Kurt Kaiser was the 
BDFL-delegate for Idle.  He has been inactive for years, but his latest 
posts here and on pydev seem to say 'Idle's basic design is fine; don't 
change or complicate it'.  Guido seems to be more approving, in 
principle, of changes, but does not seem interested in the detailed 
discussions and reviews needed to turn vague ideas into reality.  I do 
not know how big a change I can make without having the work reverted 
and dumped.

4. The dead hand of the past.

4a 2.7.  When I wrote PEP 434 (Feb 2013), 2.7 maintenance was scheduled 
to end summer 2015 (next summer), and I anticipated that Idle 2.7 would 
be frozen at the same time.  I planned to aim major enhancements at 3.x 
after that.

At the Pycon a couple of months later, 2.7 maintenance was extended 5 
years.  Around the same Nick Coughlin requested that new tests be 
backported to 2.7. I am currently unsure how to handle Idle on 2.7 in 
the future.

4b idlelib.  idlelib is currently a living mockery of PEP 8.  For 
instance, there are 5 or 6 different module name styles instead of just 
one.  In the meanwhile, work on Idle would be easier if some files were 
split or combined and all names followed PEP 8.  Although PEP 434 
defines the idlelib API, including file names, as private, it was 
written after 2.7 and there may be some external uses other than by 
extensions.  The guaranteed API for extensions needs to be pinned down 
better.  There are also issues with code inside the modules.

(At the moment I also have the problem that my hg install is broken and 
the installer will not run on my system and I don't know yet how to fix 
the situation.)

---
 >> BTW, Did you see idlex? http://idlex.sourceforge.net/

I have.  There are already issues on the tracker to incorporate some 
idlex features into Idle.  The idlex author, Roger Serwy has commit 
privileges and committed some of his patches (mostly bugfixes), but 
after two months stopped to focus on his PhD studies.

---
 > I hold the view that most professional developers don't
> really use IDLE,

I think that is a fact, not a view.  Most professional developers use 
multiple languages whereas Idle is focused on Python.

For a Python-only programmer, 'professional' or not, it can potentially 
be *better*, in some ways, than multi-language tools.  Note that there 
are many Python users, from scientists to hardware designers, who fall 
in between 'beginner' and 'professional software developer'.

> so changing the design to emphasize an educational
> tool over an experienced developer tool would benefit more people
> than it would inconvenience.

The design is already intended to be focused on beginners, such as 
students in programming classes.  According to a survey reported by 
Jessica McKeller at PyConUK 2014, Python is the third most used language 
in undergradurate courses.  So I think the proper question is how to 
make Idle better for beginners.

Yesterday I had an idea for the following problem. Uncaught exceptions 
result in a traceback followed by the exception name and message, such 
as "ZeroDivisionError: division by zero".  That line is, I hope, fairly 
clear, but many, especially beginners especially, find some other 
messages confusing.

Idlelib already has right-click context menus.  A possible improvement 
to to add an 'Explanation' option when on the last line of a traceback. 
  Selecting this would pop up a box with information about the 
exception, and possible the specific message, including possible fixes.

I have implementation ideas that I omit here.  However, I would make the 
possibility of translating the popup messages to other languages part of 
the design.

An 'Explanation' choice could be used for other lines.
For "Traceback ...", give a short explanation of what a traceback is.
For ">>> ", "Enter a Python statement on one or more lines."
For blue output lines, "Output produced by running your code."
For "**RESTART**" lines, explain user subprocess & globals clearing.

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

-- 
Terry Jan Reedy