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 <c...@users.sf.net> _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org http://mail.python.org/mailman/listinfo/idle-dev
