The  IDLEfork  Project     --    Mission Statement


IDLEfork at
Project Page
Mailing List
Python Powered
SourceForge Logo

The IDLE / IDLEfork Mission Statment

In late June 2001 there was a lot of discussion on the idle-dev mailing list about what the aims of IDLE (and therefore IDLEfork) are. As a result of these discussions, and the imprimatur of Guido van Rossum, the IDLEfork project was reborn in its currrent form, and a general set of guidelines on what IDLE is and should be were nutted out. What follows is an attempt to distill these ideas into point form as a general 'statement of purpose' for IDLE / IDLEfork, useful as a guide to anyone who is interested in the why and wherefore of IDLE.

These points are borrowed from the input of many who participated in the above discussion and are presented here in no particular order. Thanks to all who contributed to this clarification of IDLE's raison d'etre.

  • IDLE aims to be nothing more or less than a small, light, integrated development environment that is bundled by default in the standard Python distribution, with a major emphasis on being simple to use for beginners in Python programming. It should (and does) contain a debugger, editor and interactive shell window that understand the Python syntax and environment and share features such as syntax highlighting. Because of its inclusion with Python it is available to first time, casual, and resource limited users for free.
  • IDLE should remain under the ultimate control of GvR, just like the rest of Python. Neither of them would be as good as they are now if weren't for his work and stewardship.
  • IDLE's UI is written in Tkinter, and will stay in Tkinter, because it is the default Python GUI toolkit and is bundled with most python versions and is portable to many of the platforms Python runs on.
  • IDLE itself provides an extended, non-trivial example of Python and Tkinter programming.
  • IDLE should remain at roughly its current (apparent) level of complexity (or less), to avoid harming its usability by beginning / intermediate programmers.
  • IDLE development should not get tied in knots trying to be all things to all people or attempting to be completely compatible with every other Python IDE out there. When it comes to IDEs, there is obviously more than one way to do it, but Guido has shown us the IDLE way and development should continue along these lines.
  • IDLE's current stability and useability will be improved steadily and incrementally by the merging of proven new features developed in the experimental IDLEfork.
  • There's no reason to have just one Python IDE (indeed there are already many available, commercial and non-commercial, and with various approaches to the task, and there are even more in development), however, it is arguable that there should be one basic IDE that ships standard with Python under the same license agreement. IDLE fills this niche.
  • As for everyone, everywhere standardising on some same "right" IDE for their Python development work: it's never going to happen, nor should it. IDLE should merely fulfil its own role as outlined above. That role doesn't include being "the" Python IDE, even if it is the one that ships by default, as part of the standard distro.