The Python IDE Manifesto

I've been discussing over the past few days at c.l.py the state of the Python IDEs. Other threads have popped out on this same very subject since I resumed reading the mailing list a few weeks ago. To put things into perspective, IDEs are also a hot topic at one well known magazine. It's hard to keep the discussion from becoming religious. I'l try my best to respectfully put my own opinion here. However, it's a manifesto. It's meant to be opinionated and passional. Be warned.

Over the past weeks I've been looking for a good IDE to support my Python programming activities. My search has led me to literally dozens of products of varying degrees of quality. Many are broken. Some are incomplete. A few are working, but still missing some important features. After this long search, I'm still missing it somehow. I need a good, solid IDE.

What is an IDE? The acronym means "Integrated Development Environment". Any of the three words has a broad meaning of its own. The resulting expression also does have a broad meaning. I'm going to narrow it here, to put things as I understand them. For all purposes of this manifesto, an IDE is a well integrated software suite that allows a developer to do all the tasks related to his programming activities in productive environment. There's one more thing in my definition that takes IDE apart from code editors: A good IDE must provide a foundation for a RAD style of development, automating many of the tasks related to project management, and providing a high level framework for application development.

Good IDEs are a productivity tool. Bad IDEs are distracting, and that's a good reason why many programmers swear by their combination of console-based editing and programming tools.

Good IDEs are simpler than the sum of its parts. It's supposed to remove complexity, not to bring more complexity.

Good IDEs work at all levels of abstraction, from project management to simple coding tasks. It makes easy to locate and work with all the files in a project. It makes navigating the file system unnecessary for most maintenance tasks, removing a lot of clutter out of the view. On the other end, it supports all the functionality you would expect from a code editor: syntax coloring, code completion (possible even in Python), class browsers, and regular expression support, to name a few.

Good IDEs support Rapid Application Development, and that means that they are able to automate much of the stuff that is neede to make a simple project take off. That's probably the main difference between code editors and professional IDEs -- at least, that's something all the top commercial IDEs support. It goes beyond the edit-compile-run cycle. The IDE must work closely with the application framework, automatically generating parts of the code that are needed to integrate the pieces. This is essential for the visual part -- the form designer -- but by no means limited to it; it's also useful to write modules, packages, or any other stuff that is going to be integrated with the rest of the project.

Up to this point, I've been talking about good IDEs. But there's something better. The perfect IDE supports more than one style of development. Some people do network programming. Some people do scientific programming. Others do business stuff, and that's mean database access. Each type of software imposes a different approach to the development cycle. For example, a good interactive shell is a must for scientific programming, but it's not nearly as important for business app development. The debugging needs vary considerably. Each style also imposes its own framework and supporting libraries, and the perfect IDE seamlessly support them all with sound abstractions for each need.

Closing words

The perfect IDE is still a distant dream. But there's something that I need, and that I was still not quite able to find. It's a good IDE for business application development. There are some promising tools here -- Boa Constructor and PythonCard deserving special mention. But both fail to some degree, specially when it comes to the framework (or lack thereof), including the database support. And that's where the main weak spot of Python's library is today. Although a lot of tools are available, there's no integration, each one being designed and coded to solve some particular problem. It's a difficult problem to solve without a central vision. It's no wonder that the best IDEs available are all commercial offerings that include their own frameworks. It's not as if the open source community can't do it; it's probably because nobody with the required skills ever bothered to tackle it himself. But the open source community has already shown what is it capable of doing, and it may be only a question of time until it gets done.