IDLE: A cornicopia of mediocrity and obfuscation.

[Kevin Walzer]

Rick,

I've spent a fair amount of time in the IDLE source tree, putting 
together patches for various Mac-specific bugs and submitting them to 
the Python tracker, and I agree the code is crufty and disorganized. It 
is certainly not an example of current best practices in Tkinter 
development. The code base has accrued over the years, has been touched 
by many, many different hands, and I think its current messy state 
reflects that legacy.

But, as I understand it, the purpose of IDLE is not to provide a 
pedagogical example of Tkinter programming practices, but instead to 
provide a lightweight development environment for those learning Python, 
to interactively explore different aspects of Python. For this it serves 
its purpose well. I use IDLE a good deal for my Python development work, 
and the cruftiness of the code under the hood is not an impediment to me 
getting my work done (unless the work is patching IDLE itself).

Given this, I don't see any huge need to bulldoze IDLE to the ground and 
replace it with something else, or even do massive rewrites of the code, 
unless such a project also significantly improved the user-facing 
portions of IDLE as well. However, there are certainly no impediments 
for you undertaking such a project yourself: similar efforts have been 
undertaken in the past and, as I understand it, have led to some 
significant improvements in IDLE's performance. Here's the one I'm 
thinking of:

http://idlefork.sourceforge.net/

According to this project's details, IDLE was forked, numerous changes 
were made to its code base, the new version of IDLE gained a user base, 
and eventually the changes were merged back in to Python's main line of 
development.

It certainly would be interesting to see a fresh approach to IDLE, and I 
think the scope of such a project would be much easier for a single 
person to manage than would replacing Tkinter in the stdlib with another 
GUI toolkit, such as wxPython, or pyGUI, or something else. I'd 
encourage you to set up a project page somewhere, begin cutting some 
code, and then invite feedback from other users and/or developers. I 
think that approach has a much better chance of getting off the ground 
and making progress than long threads on c.l.py.

Good luck!

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com