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

[Sean Felipe Wolfe]

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