[Idle-dev] IDLE 2.6.4 crashes constantly

[Beni Cherniavsky]

Guilherme Polo <ggpolo <at> gmail.com> writes:

> VIDLE hasn't been ported to 3.x too, that is what I know at least.
> 
What's the 2.x/3.x strategy of IDLE?  Should I duplicate patches for both 2.x
and 3.x simultaneously or is there some shortcut?

Also, on what Python and Tk versions should I test patches?

[Hi guys.  New here, had some experience hacking a diverged relative of 
IDLE-Spoon a few years ago with Noam Raphael and Tal Einat...  
Still have an itch to move IDLE forward.]

> From what I've seen from the VIDLE code base I can tell you that is is
> very conservative about the changes applied on it. In fact, most of
> its earlier changes were already merged in Python's IDLE. IDLE-Spoon
> adds some good changes, but VIDLE is mostly (from what I understood
> after reading it) about fixing bugs that would take too long to get
> into the next python release and also add some other minor but good
> improvements.
> 
As far as I see, your tk_and_idle_maintenance branch includes all changes 
in VIDLE - right?  But few of your changes has been applied to the trunk?

I also see patches in the issue tracker (many by you) that are seemingly 
ready to be applied, waiting for review a long time.

So there are low-hanging fruits for improving the trunk.  Is there 
something I could do to help this (like triage a list promising patches)?

> It is interesting to see that you mention that forking IDLE may result
> in a wider user-base because of the inclusion of new interesting
> features. But I bet that didn't happen, did it ? At some point I
> though about the possibility of moving IDLE to somewhere else,
> removing it from python's trunk. It doesn't seem appropriate to
> include an editor into the stdlib, from my POV it is at least strange.

I see 2 central problems with having IDLE in Python's core:

1. Experimental IDLE changes don't get wide testing, except for when 
   Python is undergoing the alpha/beta cycle - but that only happens 
   once ~1.5 years.  Since IDLE is also hard to unit-test, this hampers 
   bold experimentation.

2. IDLE is bound by the core development policies, which slow down

> It could continue being distributed with the windows installer, and
> continue being distributed separately by Linux distributions and etc..
> For now what I believe is that forking IDLE is not going to help it in
> any way, specially because it takes too long to get anything into
> python's trunk that is outside critical real-life bugs 

Isn't that precisely the reason IDLE *should* be developed outside of 
Python?

> and also
> because there is a lot of people using IDLE in a first contact with
> Python and surely doesn't know there is some better fork of it around.
> 

In my humble outsider opinion, IDLE needs:

- A single place where adventerous users can get bleeding-edge 
  IDLE versions, all year long.  A windows installer is a must.

- A low barrier to entry for code contributors - freely handed commit 
  rights and/or a distributed VCS.  Python is planning a switch to 
  Mercurial - IDLE seems to me a great guinea pig for it.

The official Python install should still include "stable" IDLE versions.
But they would be produced by periodically forking the unstable branch 
and bug-fixing that, not by reviewing every single change that is to be 
merged.

-- 
Beni Cherniavsky <cben at users.sf.net>