A Python IDE idea - looking for input

[Paul Boddie]

"Brad Bollenbach" <bbollenbach at home.com> wrote in message news:<2u8Z7.24814$L4.2838063 at news2.calgary.shaw.ca>...
> 
> There are really only two things in VB's IDE that are worth trying to
> reproduce: the form designer, and the debugger. Everything else that VB does
> can be handled by common sense (like "project managers"), and a decent text
> editor (for a good laugh, compare vim to VB's editor).

For me, tight integration with CVS would be a requirement - there
would be no needless "declaring" of files in projects in my ideal IDE.

> Further, a form designer is only useful for those whose problems involve
> GUI's, and a debugger is only really useful to those who don't find the one
> included with Python to be useful and who don't think the simplicity of the
> language itself greatly reduces the need for a debugger to begin with.

While debuggers are useful - very useful for programs written in C,
for example - the simplistic trace statement approach works well in
Python, especially if one has done a fair amount of testing on various
program components before putting them together. I heard that certain
IDEs for Java are now increasing their support for unit testing, and
this would be nice for any ideal Python IDE.

Of course, the GUI-centric nature of some IDEs is part of a much
larger "turn off" for many developers: can the IDE support development
in widely varying environments, such as Web or application server
modules/components? Not everyone is writing graphical client software,
but that is surely the emphasis of VB.

I think many people approach the "what there should be in an IDE"
issue from a very narrow mindset, imposed by the variety (or
similarity) of existing IDEs. One only has to look at screenshots of
almost any commercial or open source IDE to see the blatant
similarities of them all - indeed, it's usually possible to predict
what an IDE will look like before clicking on the "screenshots" link
on any given Web site promoting an IDE.

A more interesting IDE-like project would support new developers and
scale up to being generally useful for experts. I can imagine having
visual representations of Python data types with instances of those
types showing their contents in a window (or frame) representing the
current namespace, and such representations alone would be a powerful
replacement for the archaic spreadsheet concept. Users would be able
to manipulate the contents of the representations directly, or by
using the Python prompt, but each manipulation would be reflected in
all of the available representations, so that a change to a list
element might be reflected in the "Python console" by the appearance
of an assignment statement involving that list element.

More advanced usage could be supported by letting users change the
representations by defining different kinds of views, and this would
effectively permit the development of form-based interfaces. One could
also be able to determine whether the introduction of a new namespace
(due to a function call, for example) would open a new window, or
instead affect the contents of an existing window.

The challenge in such a project would be to find a good representation
for activities rather than data and for abstract data "containers"
rather than concrete data items. Of course, one might suggest that
textual Python source code is a good enough representation for program
tasks, but it would be nice to be able to see how that code
manipulates the data, or at least be able to step through running code
one line at a time. And that brings us right back to debugging
tools...

Paul