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
--
http://mail.python.org/mailman/listinfo/python-list
