Guido van Rossum wrote:

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

Isn't separate distribution the way the *current* version of Idle was developed? I seem to recall it existing as IDLEFork for a long time so that it could have a more rapid release cycle before being rolled into the main distribution. This approach also allows a wider audience to asess the subjective benefits of any changes made - many more people will download and try out a separate IDE than will download and try out a patch to the main distribution. I'm such a one, even though I believe my main problems with Idle lie in the Tcl/tk toolkit (so I don't expect any application level changes to alter my opinion much). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

On 9/11/05, Guido van Rossum wrote:

On 9/10/05, Noam Raphael 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