[Idle-dev] IDLE development [moved from python-dev]

[Kurt B. Kaiser]

Noam Raphael <noamraph at gmail.com> writes: (on python-dev)

> More than a year and a half ago, I posted a big patch to IDLE which
> adds support for completion and much better calltips, along with some
> other improvements. Since then, I had some mail conversations with
> Kurt B. Kaiser, who is responsible for IDLE, which resulted in
> nothing. 

It resulted in my requesting some changes to what I felt was becoming
a very noisy interface.  You incorporated those changes 10Jul05.

> My last mail, from Jul 10, saying (with more details) "I made
> the minor changes you asked for, let's get it in, it's not very
> complicated" was unanswered.

Considered as a whole, the patch is a significant (and welcome)
addition to IDLE.  In fact, I need to ask you to send a contributor
agreement:

http://www.python.org/psf/contrib-form-python.html

Please note that there are two places on the form for you to sign so
that your previous Code Context patch will be covered.

The form address contains an error.  Please send the form to

Python Software Foundation
P. O. Box 653
Ipswich, MA 01938

Instructions for the form are at

http://www.python.org/psf/contrib.html

While I'm waiting for your form, I'll go ahead and incorporate the
patch on my system.  I may have additional comments :-)


In the future, please post on idle-dev or at least copy idle-dev.  I
sometimes go several weeks between scans of python-dev, which is why I
didn't see your post and the subsequent thread.

=================================>

> 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. 



A reasonable suggestion.  I thought of using IDLEfork, but I don't
want to encourage people to use the IDLEfork Tracker.  They should
use the Python Tracker for IDLE Patches/Bugs/RFE.  So we would need
to find another location that doesn't have a bug reporting mechanism.

For those who like to be on the bleeding edge, it's easy to replace
your .../Lib/idlelib with the CVS version without building all of
Python or even synching your CVS checkout to anything except idlelib.
If anyone would like instructions on how to do that, please ask.


> 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.


Those maintenance releases are intended to be of increasing stability,
with changes limited to bug fixes.


> 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... :)

:-)

-- 
KBK