From al at inventwithpython.com  Wed Apr  1 01:22:42 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Tue, 31 Mar 2015 16:22:42 -0700
Subject: [Idle-dev] Going to PyCon 2015?
In-Reply-To: <d9d86f9e9cdaa36f19d7276900a38f7e.squirrel@mail.cs.brynmawr.edu>
References: <CAM=hmRPF66Xw9OX23Rpfzux6rXNzzJxpmQoMnktKw9k7nF8aJQ@mail.gmail.com>
 <d9d86f9e9cdaa36f19d7276900a38f7e.squirrel@mail.cs.brynmawr.edu>
Message-ID: <CAM=hmRP1BTZAi2Uw=UVaoJ=coXctsGgi1q0XmzGTjZWTzRYEjw@mail.gmail.com>

Oh yes, I have looked at IdleX and I like many of its ideas. But
mostly I wanted to make improvements to the IDE that comes bundled
with Python (which means sticking with tkinter and the standard
library). I hold the view that most professional developers don't
really use IDLE, so changing the design to emphasize an educational
tool over an experienced developer tool would benefit more people than
it would inconvenience. I have more concrete ideas on the wiki:
https://github.com/asweigart/idle-reimagined/wiki

-Al

On Tue, Mar 31, 2015 at 2:01 PM, Douglas Blank <dblank at cs.brynmawr.edu> wrote:
> On Tue, March 31, 2015 4:54 pm, Al Sweigart wrote:
>> Are any IDLE developers or enthusiasts going to PyCon in Montreal? I'd
>> like to meet up and talk about some ideas.
>>
>> 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
>> ideas off of IDLE developers (or anyone who has ideas/critiques).
>>
>> -Al
>
> Al, I'm not going to be able to make it, but that sounds like a great
> conversation!
>
> BTW, Did you see idlex [1]? Using the IDLE interface to a Jupyter backend.
> That looks like an interesting direction. That might be a way to include
> more educators than just those interested in CPython.
>
> Good luck with your talk, and plans,
>
> -Doug
>
> [1] - http://idlex.sourceforge.net/
>
>

From tjreedy at udel.edu  Sun Apr  5 21:59:31 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 05 Apr 2015 15:59:31 -0400
Subject: [Idle-dev] Re-imagining Idle (was re; going to pycon
In-Reply-To: <CAM=hmRP1BTZAi2Uw=UVaoJ=coXctsGgi1q0XmzGTjZWTzRYEjw@mail.gmail.com>
References: <CAM=hmRPF66Xw9OX23Rpfzux6rXNzzJxpmQoMnktKw9k7nF8aJQ@mail.gmail.com>
 <d9d86f9e9cdaa36f19d7276900a38f7e.squirrel@mail.cs.brynmawr.edu>
 <CAM=hmRP1BTZAi2Uw=UVaoJ=coXctsGgi1q0XmzGTjZWTzRYEjw@mail.gmail.com>
Message-ID: <mfs47v$k25$1@ger.gmane.org>

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


From ether.joe at gmail.com  Sun Apr  5 22:32:05 2015
From: ether.joe at gmail.com (Sean Felipe Wolfe)
Date: Sun, 5 Apr 2015 13:32:05 -0700
Subject: [Idle-dev] Re-imagining Idle (was re; going to pycon
In-Reply-To: <mfs47v$k25$1@ger.gmane.org>
References: <CAM=hmRPF66Xw9OX23Rpfzux6rXNzzJxpmQoMnktKw9k7nF8aJQ@mail.gmail.com>
 <d9d86f9e9cdaa36f19d7276900a38f7e.squirrel@mail.cs.brynmawr.edu>
 <CAM=hmRP1BTZAi2Uw=UVaoJ=coXctsGgi1q0XmzGTjZWTzRYEjw@mail.gmail.com>
 <mfs47v$k25$1@ger.gmane.org>
Message-ID: <CAOFf2a0mfRkZRjvqyo5pjSBcm6kmK+cH-BMQQ2+64H4W8DfpCA@mail.gmail.com>

Hello!

I am still interested in helping out with idle development.

I feel like we need a stronger identity and direction to know that our
efforts are proceeding towards a specific goal or release point. I
have picked up some tickets and done a little bit of work, but
sometimes I feel like it gets lost in the ether.

For example, I would like to do work towards getting the terminal
enhancements from idleX -- up-arrow triggers previous commands +
typing when not clicked on the >>> line defaults you back to that line
-- incorporated into the mainline code for release.

I'm still interested and should have some time available as my work
encourages opensource contributions.

IDLE on!!

On Sun, Apr 5, 2015 at 12:59 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> 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
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev



-- 
A musician must make music, an artist must paint, a poet must write,
if he is to be ultimately at peace with himself.
- Abraham Maslow

From tjreedy at udel.edu  Mon Apr  6 00:28:35 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 05 Apr 2015 18:28:35 -0400
Subject: [Idle-dev] Re-imagining Idle, Killer App
Message-ID: <mfscvf$m2h$1@ger.gmane.org>

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


From al at inventwithpython.com  Tue Apr 14 20:27:19 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Tue, 14 Apr 2015 14:27:19 -0400
Subject: [Idle-dev] Updates to the IDLE Dev Guide
Message-ID: <CAM=hmROARiHQD1gEgLPJ2jOgk7_5iV-3vud9N8nZSUuROBkOKQ@mail.gmail.com>

I'm trying to revamp the IDLE Dev Guide on Phil Jone's github account.
For now I've added a few tkinter resources and links, but eventually
I'd like to add high-level descriptions of each source file in the
idlelib folder.

It'd be great if others could add to it. Especially if you are
familiar with how to run IDLE's test suite.

-Al

From al at inventwithpython.com  Tue Apr 14 23:02:56 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Tue, 14 Apr 2015 17:02:56 -0400
Subject: [Idle-dev] Updates to the IDLE Dev Guide
In-Reply-To: <9a8d8df525e6db7eba8a7849afcf6ab0@cs.brynmawr.edu>
References: <CAM=hmROARiHQD1gEgLPJ2jOgk7_5iV-3vud9N8nZSUuROBkOKQ@mail.gmail.com>
 <9a8d8df525e6db7eba8a7849afcf6ab0@cs.brynmawr.edu>
Message-ID: <CAM=hmRM-MkUvEOz3wQZMFQjYqy1TCYo96E9yR1HnRb=hCve5Mw@mail.gmail.com>

Yes. Sorry, I failed to paste the link.

On Tue, Apr 14, 2015 at 2:39 PM, dblank <dblank at cs.brynmawr.edu> wrote:
> On 2015/04/14 2:27 pm, Al Sweigart wrote:
>>
>> I'm trying to revamp the IDLE Dev Guide on Phil Jone's github account.
>
>
> Do you mean this repo:
>
> https://github.com/interstar/idle-dev-faq
>
> -Doug
>
>
>> For now I've added a few tkinter resources and links, but eventually
>> I'd like to add high-level descriptions of each source file in the
>> idlelib folder.
>>
>> It'd be great if others could add to it. Especially if you are
>> familiar with how to run IDLE's test suite.
>>
>> -Al
>
>

From tjreedy at udel.edu  Fri Apr 17 00:22:42 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 16 Apr 2015 18:22:42 -0400
Subject: [Idle-dev] Updates to the IDLE Dev Guide
In-Reply-To: <CAM=hmROARiHQD1gEgLPJ2jOgk7_5iV-3vud9N8nZSUuROBkOKQ@mail.gmail.com>
References: <CAM=hmROARiHQD1gEgLPJ2jOgk7_5iV-3vud9N8nZSUuROBkOKQ@mail.gmail.com>
Message-ID: <mgpcnm$ci7$1@ger.gmane.org>

On 4/14/2015 2:27 PM, Al Sweigart wrote:
> I'm trying to revamp the IDLE Dev Guide on Phil Jone's github account.

I got the link from the response.  I don't believe it has been announced 
here before, hence I was not aware of it.

> For now I've added a few tkinter resources and links, but eventually

The material at that link *might* become a chapter or addendum to the 
general devguide.  Or put in idlelib.

> I'd like to add high-level descriptions of each source file in the
> idlelib folder.

On my list of todo's.  I know enough now to write such discriptions.  So 
I should do so.

> It'd be great if others could add to it. Especially if you are
> familiar with how to run IDLE's test suite.

I already wrote idlelib/idle_test/README.txt as a 'devguide' for writing 
and running Idle tests.  I refer back to it myself for forgotten details.

-- 
Terry Jan Reedy


From al at inventwithpython.com  Fri Apr 17 03:01:56 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Thu, 16 Apr 2015 21:01:56 -0400
Subject: [Idle-dev] Updates to the IDLE Dev Guide
In-Reply-To: <mgpcnm$ci7$1@ger.gmane.org>
References: <CAM=hmROARiHQD1gEgLPJ2jOgk7_5iV-3vud9N8nZSUuROBkOKQ@mail.gmail.com>
 <mgpcnm$ci7$1@ger.gmane.org>
Message-ID: <CAM=hmRP=Kx5Fjbk9rX9uiqJtc2s77Bc7ro-7S6RXihWQsbVURA@mail.gmail.com>

Oh excellent, Terry. I've posted a patch to edit the idle_test readme:
https://bugs.python.org/issue23964

Mostly I wanted the info about how to run the tests at the very top in
the "Instant User's Manual" section. I reworded some parts slightly,
but feel free to comment on any changes that might not be accurate or
missing details.

On Thu, Apr 16, 2015 at 6:22 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 4/14/2015 2:27 PM, Al Sweigart wrote:
>>
>> I'm trying to revamp the IDLE Dev Guide on Phil Jone's github account.
>
>
> I got the link from the response.  I don't believe it has been announced
> here before, hence I was not aware of it.
>
>> For now I've added a few tkinter resources and links, but eventually
>
>
> The material at that link *might* become a chapter or addendum to the
> general devguide.  Or put in idlelib.
>
>> I'd like to add high-level descriptions of each source file in the
>> idlelib folder.
>
>
> On my list of todo's.  I know enough now to write such discriptions.  So I
> should do so.
>
>> It'd be great if others could add to it. Especially if you are
>> familiar with how to run IDLE's test suite.
>
>
> I already wrote idlelib/idle_test/README.txt as a 'devguide' for writing and
> running Idle tests.  I refer back to it myself for forgotten details.
>
> --
> Terry Jan Reedy
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev