[Idle-dev] [Python-Dev] Removing IDLE from the standard library

[Kurt B. Kaiser]

On Mon, Jul 12 2010, Tal Einat wrote:

> On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>> FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's
>>> project of the same name, in a sense). The idea was to have a fork of
>>> IDLE with new features which need to be tried out by "beta testers" to
>>> iron out all of the glitches before making it into the main version,
>>> like IDLE-fork back in the beginning of the decade. However I have
>>> utterly failed in promoting this project and getting "beta testers" on
>>> board, at least partially due to the lack of interest from the
>>> community (and admittedly my lack of PR skills).
>>
>> I think such a thing must inherently fail - precisely for these reasons.
>>
>> It's much better to release proposed new features along with Python,
>> and wait for feedback. Users won't start trying things out until after
>> the release. This is a general problem, and lead Barry Warsaw to believe
>> that "release candidates" are an utter waste of time.
>
> That's debatable, and I disagree. IDLE-fork was a great success, for example.

We had major contributions from David Scherer, Guido, and Stephen Gava.

But a key factor in its success was that I took it upon myself to keep
IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent
merges.  Once the project was completed, I arranged with SF to move the
IDLEfork repository, including history, back into Python.

This was not done with Noam's branch.  As a result, it gradually drifted
to the point where it became essentially unmergable.

Once we switch to Hg, we should be able to use distributed vc and topic
branches to facilitate community participation without the need for a
separate project.  None of this is automatic, of course, it requires
diligence, planning, and clean topic patches.

>
> If IDLE actually had many users today, certainly some of them would be
> interested in trying out a version with usability fixes and
> improvements. Waiting for a new release of Python can take over a
> year. Furthermore, backwards compatibility issues and support by third
> party libraries can delay migration to a newer version of Python even
> further.

There's no reason why we couldn't release interim IDLE testing packages
from somewhere other than python.org (for those that don't want to track
IDLE's Hg repo).  To do this successfully, we would need to avoid using
new Python features being introduced during that development cycle,
i.e. IDLE would be compatible with the previous Python release.

-- 
KBK