[Python-Dev] IDLE development
Noam Raphael
noamraph at gmail.com
Sun Sep 11 07:06:36 CEST 2005
On 9/11/05, Guido van Rossum <guido at python.org> wrote:
> On 9/10/05, Noam Raphael <noamraph at gmail.com> wrote:
> > I and my colleges use IDLE intensively - that is, a heavily patched
> > IDLE. It includes my patch and many other improvements made by me and
> > my friends.
> >
> > The improved IDLE is MUCH better than the standard IDLE, especially
> > for interactive work.
>
> Could it be that this is a rather subjective judgement? It wouldn't be
> the first time that someone pushing for their personal set of
> functionality changes is overlooking the needs of other user groups.
>
I don't think so, since:
1. These are added features, not functionality changes.
2. There are quite a lot of people using the improved IDLE where I
work, and I never heard anyone saying he prefers the standard IDLE -
on the contrary, many are asking how they can use the improved IDLE in
their homes.
3. Kurt agreed to integrate the change - he just didn't do it.
> > Since we would like to share our work with the
> > rest of the world, if nothing is changed we would start a new IDLE
> > fork soon, perhaps at python-hosting.com.
>
> I have no problem with this. You might be able to save yourself some
> maintenance work by structuring your version as a set of subclasses
> rather than a set of patches (even if you distribute it as a complete
> working program). Many people have needs that aren't met by standard
> Python; they write their own modules or extensions and distribute
> these independently from Python; your case probably isn't all that
> different.
>
I think that rewriting the patches as subclasses will be a lot of
work, and won't be a very good idea - if you change one line in a
function, copy-pasting it to a subclass and changing the line seems a
little weird for me - not to mention the cases where some refactoring
needs to be done. I think we will be talking about a separate package
- say, idleforklib instead of idlelib. You can always run diff to find
the differences between the two packages.
> Often the needs of certain user groups and the development speeds of
> such 3rd party modules are so different that it simply doesn't make
> sense to fold them in the Python distribution anyway -- consider what
> you would have to do if Kurt accepted your patches: you'll still have
> to wait until Python 2.5 is released before others can benefit from
> your changes, and if you come up with an improvement after that
> release, your next chance will be 18 months later...
>
I don't think so - if IDLE is developed on the Python CVS, we can
still distribute a stand-alone package with IDLE from the CVS head,
for eager people. All others will get the changes a year later, which
isn't that bad. Perhaps it can even be less than a year - since IDLE
is a GUI application and not a library, so there isn't a lot of
backward compatibility to maintain, it seems to me that updated
versions can be shipped also with new minor versions of Python.
The advantages of developing IDLE on the Python CVS are that there is
no need to synchronize two versions, and a wider audience. Of course,
after you see the improved IDLE you will surely decide to immediately
import it into the Python CVS, so there's not much of a problem... :)
Noam
More information about the Python-Dev
mailing list