[Idle-dev] IDLE 2.6.4 crashes constantly
cben at users.sf.net
Wed Apr 7 16:08:34 CEST 2010
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
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
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
> 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
Beni Cherniavsky <cben at users.sf.net>
More information about the IDLE-dev