[Idle-dev] Totally Wacky Proposals / Feature Requests

[Glyph Lefkowitz]

Note: this message is rather stream-of consciousness.  Requests for
clarification or explanation will be honored as promptly as my schedule
allows, as I realize that some of this might be confusing or
ill-described.

I just finished reading the entire idle-dev archive, and I'm suitably
impressed.  However, it seems to me that IDLE's development is going the
same route as many free and commercial IDEs before it, in that it has the
same flawed assumptions about an "interactive" interface, "files",
"projects", et. al.

Before I get myself into any more trouble :-) let me say that I am the son
of an "old school" hacker who has some really kooky ideas about the way
that interactive environments should work.  He (my father) is currently
tinkering with starting a very ambitious multi-language multi-interpreter
platform-independent interactive development system, so some of my ideas
are lifted nearly directly what he's said about that.  I also don't have
any idea how to design half of the things I'm talking about here, let
alone implement them, so I will understand perfectly if everything I say
is ignored.  I just hope that this raises some potential issues for IDLE's
design that challenges everyone's basic assumptions about the way IDEs
should work in general, and maybe makes IDLE truly rise above the rest.

First of all, let me share some of my own experiences with interactive
environments, specifically in python.  I am developing a multi-threaded,
client/server application using GTK in python. When I started the project,
I was editing a single file, tinkering with the API.  Mostly, I had the
file because the interactive session was really crappy to copy-and-paste
from; I was just re-running the same small file.  (I note that, completely
beyond the scope of Python's culpability, PyGTK has a very annoying habit
of *completely* ignoring keyboard interrupts, so I always have to kill it
manually.)

Obviously, IDLE is currently unsuitable for this sort of development.  
GTK+threading constantly crashes Tkinter's event loop, it's not possible
to simultaneously debug a client and a server in one IDLE instance,
etcetera.  Although some of these concerns will soon be resolved (the
XIDLE seems to at least take care of the first one) a great many issues
remain problematic even if IDLE is completely successful at what I
perceive as its current goals. (Again, I may be wrong!  I have attempted
to do my research on this front, but there isn't a perfect project-outline
on the web as to what features and paradigm IDLE intends to pursue, so I
am mostly working from hearsay)

If IDLE were to move to a more 'project' centric model, as other IDEs
have, that scratch file would have no place in my "project"; it's just
some extra state and cruft that I want around for my interactive
interpreter sessions so I can experiment with the various APIs that I'm
using, not an actual piece of code I want linked into my released
application.  Unless you're sticking with "100% pure python" (no outside
libraries) though, such experimentation seems intrinsic to the development
process (especially since **NO** native API bindings seem to have
docstrings! ^_^) and the results of it should be more easily reusable.

Now ... here's an interesting question.  I'm working with one session
that's got lots of state, and I think to myself, "hey, I wonder what would
happen if I had done it *this* way instead?"  I would ideally like to be
able to compare the results of both side-by-side in a somewhat interactive
manner.  First of all, if I've got lots of state, it would be super-nice
if I could *save* that state so I could diverge in my experimentations at
some point without re-running everything (especially if the session is
interactive).  Moreover, if I define a function in one that would be
useful for the other, I'd like to be able to move it from one to the
other.

Which leads me into what I suppose is my main point here; we all know how
cool it is that python treats functions, modules, and classes as objects.  
Why should the IDE be any different?  The path browser is very nice (IMHO
the best feature of IDLE so far ^_^) and a step in the right direction,
but it's not very interactive; it's just a static listing of pre-existing
code in a prettier format.  For an example;

Let's say I'm working in an interactive session, re-typing and
re-evaluating the same function over and over again, and testing it.  
Once I'm done with that, I have to go back to the file that I'd like to
put it into, and likely as not, retype the whole thing (at least IDLE
takes away those pesky '...' prompts so I don't need to manually remove
them) in order to integrate it.  Regardless of the previously-debated
effects of hitting the up-arrow or backspace or the return-key on a blank
line, I don't like that interface at all; imagine something more along
these lines:

I type 'def foo():' at an interactive interpreter.  A window pops up (or a
buffer opens, or whatever) entitled "<function> __main__.foo".  I enter
the code to my function there.  Then I hit 'evaluate'.  I go back to my
interactive interpreter window, I run the function, it produces incorrect
output, I go back to my popup window, tweak the function, hit 'evaluate'
again... after a few iterations of this, the function works properly.  
Somehow (if someone thinks that I'm not insane, feel free to push me for
specifics on more of this) you drag the 'icon' of this newly defined
function into a module that I'm working on.

It's essentially the same effect as copying something from the interactive
interpreter into a module you're working on, or having a 'dummy' module to
do work like this in; but the advantages of a more object-oriented
approach seem obvious to me.  At a simple level, rather than manually
adding tabs and spaces, the editing phase of this would be transparent;
you move code into the appropriate container (and of course, moving
functions into classes would turn them into methods, along with the
displayed warning that the functionality is slightly different and the
user should test again...).

The 'incremental' development process could be greatly sped up, as each
component down to the smallest detail could be removed and tested
independently, before integrating them into a whole.

Lifting an idea directly from my father's design plans; it would also be
highly useful to be able to bring up a window for a variable in a
particular namespace, and watch it in real-time as it changes (I know that
the debugger can do something like this, but you effectively have to stop
the program in order to see it).

Speaking of debugging; remote debugging is a must, but in the age of the
internet, the ability to remotely debug multiple interpreters / threads
simultaneously is equally critical.  I have yet to see a development
environment in which I may comfortably work on a client/server
combination, especially one which communicates over some sort of remote
object protocol, and very few that can properly handle multithreaded
programs.

Built-in version control would also be nice.  It would be good to be able
to go to any module (I refuse to say 'file' in this context ^_^) and
retrieve the contents of that module on a given date.  Support for a
CVS-like interface (not actually using CVS; CVS is rife with the sort of
anachronistic UNIX idiosyncracies that I gather CP4E is attempting to
avoid) to enable collaborative projects would really be useful.

One existing interface which escapes the traditional project paradigms in
a rather novel, although highly domain-specific, way is the Mathematica
"notebook" interface.  I haven't used it very much myself, but it's an
interesting concept; you run your code (code, equations, whatever...) and
each block of input is saved with its block of output, along with all the
state that that generated, so you can go back again and poke at it. Those
on this list who are running physics simulations would probably enjoy
something to this effect; any traditional computation-oriented programming
probably has input, code, and output, and being able to look at all three
in a format that juxtaposes them would be helpful.

Okay.  That's my $0.02, although probably more like $0.08...

                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m
                     http://www.twistedmatrix.com/~glyph/