[Idle-dev] Running a program

[Guido van Rossum]

(Changing the subject, widening the audience.)

[KBK:]
> I have used DrScheme.  They have a good system in which once the code
> is run in the remote window you can use that window as a shell to
> examine the environment and define and run procedures, like you would
> in the Python shell.  It doesn't disconnect like the DS code does.
> However, if you change the text in the Edit window, the remote window
> is marked as out of synch and you have to re-run the code.  Doing that
> restarts the remote REPL with a fresh environment.  One nice thing
> with DrScheme is you can cut/paste back and forth between the two
> windows.  Last I heard, a new version was in alpha.
> 
> http://www.cs.rice.edu/CS/PLT/packages/drscheme/tour/slide10.htm 
> 
> I think that is close to what Guido wanted:
> 
> http://mail.python.org/pipermail/idle-dev/2001-July/000504.html
> http://mail.python.org/pipermail/idle-dev/2001-July/000506.html
> 
> and, as you suggest, with that approach we don't need a separate
> shell.  Perhaps if you F5 an empty edit window it brings up a shell?
> With DrScheme, the shell is always present and attached below the edit
> window.  In our case, do I understand that the presence of the shell
> at startup is now a user config?
> 
> http://mail.python.org/pipermail/idle-dev/2001-October/000663.html
> 
> Personally, I don't think the DrScheme design is a very good use of
> the screen and I would rather see side by side windows (maybe with a
> tabbed Edit window?) or floating windows.  If the latter, they should
> remember their positions and sizes between sessions.

I've thought some more about what I think I would like.  (You never
know if I'll like it once I have it of course. :-)

- The presence of the PythonShell window corresponds with the presence
  of a subprocess running user code.  Close the window, the subprocess
  exits.

- There can only be one PythonShell window at any time.  (This is not
  technically necessary, but makes it easier for the user to avoid
  confusion.  If we can technically allow multiple windows, expert
  users can turn this on.)

- It's configurable whether initially you get a PythonShell window or
  a blank, "new file" window.  I think for historic continuity the
  default should be a blank window in IDLEFORK, but if/when all is
  backported to the Python CVS tree, the default should be a
  PythonShell.  There should be a command line option to force either
  choice (overriding the user's configured preference).

- When you invoke idle with one or more filename arguments, those
  files are edited and no PythonShell window pops up (also no blank
  window of course).

- If you edit a file and hit F5, the program's output appears in the
  PythonShell window and after that the user can interact with the
  PythonShell.

- F5 should first save the buffer, without asking.  If there's no
  filename yet, it should silently save to a temp file.  (Or maybe it
  should always save to a temp file so that if you have unsaved
  changes you can run the program without making the permanent?  This
  could be a useful feature.)

- If there was alread a PythonShell window when you hit F5, I'm not
  sure what should happen; either a separator should be appended and
  the new output should be appended, or the window should be cleared
  first.  I now think that I like clearing first better.  Maybe make
  this configurable?

- (Very important, based on user testing!)  If you hit F5 while the
  current window is the PythonShell, the program that was last run
  should be run again.  If no program was run yet, a simple error box
  should pop up.  (Hm, maybe you could pop up a file selector box to
  select the file to run, but that's probably not what the user
  wanted.)

- I don't want the "transparent" property of DrScheme from the
  rice.edu URL quoted above (warnings when you type in the shell after
  editing your program).

- I don't like DrScheme's multiple panes approach; let the PythonShell
  window be a totally separate window.

- It's a good idea to remember window positions across sessions.

- If you hit control-F5, a dialog box pops up that lets you change
  some things:

  - a checkbox to enable the debugger

  - you can type command line arguments that are parsed and stored in
    sys.argv of your program

- If after using control-F5, you run your program again with F5, the
  settings from the dialog box are used.

That's all I can come up with for now.

(Oh, when the program ends with a traceback, maybe you should be
thrown into the debugger?  Or at least this could be an option?  Or
maybe the "stack viewer" thingy could be the default behavior? Hm,
the stack viewer is more powerful than the regular debugger when
inspecting objects -- the debugger should use this too.)

--Guido van Rossum (home page: http://www.python.org/~guido/)