[Idle-dev] Big change to IDLE Shell

[Terry Reedy]

On 5/13/2021 7:27 PM, Alan Gauld via IDLE-dev wrote:
> On 13/05/2021 22:32, Terry Reedy wrote:
> 
>>> Great news, that will eliminate a whole category of problems
>>> we see on the tutor list with IDLE.
>>
>> Could you summarize your experience here with a post on
>> "Beginner problems with IDLE"?
> Without trawling through the archives I can't be scientific,
> however, here are my anecdotal memories...and in no
> particular order:

This is *very* helpful.  Guido has said (parapharsing) "Keep IDLE for 
beginners; don't imitate professional IDEs".  But how do I tell the 
difference.

All your items except shell indents and tabbed windows are about more 
easily saving and running code, including code from elsewhere.  This is 
a nice goal list for the next year.

> 1) The indentation issues being addressed in the current change

> 2) The inability to paste code from web sites into IDLE (you
>     have to do it one line at a time and wait for the
>     interspersed results. This is, of course, due to the
>     interpreter in the shell, not really an IDLE issue but
>     complete beginners don't understand that.

In IDLE Shell, one can paste a *statement* rather than just a line. 
History recall also recalls statements rather than lines.

One can instead paste multiple statements into the editor and run. 
There is an issue, I believe, to be able to run without 'saveas'.  The 
pseudofile name used in tracebacks could be <untitled> rather than 
<pyshell> (for shell entry).

I have though about the possibility of allowing multi-statement pasting 
into Shell by using ast.parse to separate into top level statements.

A different between IDLE and console REPL is that IDLE allows one to 
check and edit pastes before running.  I don't want to lose that.  But 
the important point you have revealed is that beginners do a lot of 
copy-pasting-running of code from elsewhere and would like it to be even 
easier.

> 3) The inability to save an interactive session then

We intended to have 'save code' in the recently .0b1 release.  But it 
also saved responses to `input(prompt)` in user code.  So we first have 
to fix such input getting the same tag.

A variation could be 'save code & output', where output would be in 
comments.  But what to do with input() response?

>     reload/replay it. This is more interesting.

We could add 'Simulate interaction' to the 'Run custom' box.  Print a 
statement, wait for output, print a statement, ...  See below.

> The old VAX
>     debugger used to be able to do that by simply prefixing
>     everything with a comment marker when saving and then
>     interpreting lines beginning with comment+prompt (#DBG>)

I have a separate idea about using the debugger to 'animate' a program 
-- step through at a user controllable speed.

>     on reload. Something similar could probably be done in
>     IDLE although multi-line commands make it more tricky..

ast.parse should solve this.


> 4) The ability to copy/paste code (without the prompts)
>     into a file (either a project or a web post/email request)
>     while retaining formatting.

What does 'retaining formatting' mean?

> 5) Tabbed edit windows (already in IdleX).

Tabbed windows, with not just editors on tabs, was one of my initial 
goals 11 years ago, along with using ttk widgets (done).  Other things, 
including a bit of opposition, keep intervening.  I will increment its 
priority.

After Roger Sewey, IdleX author, got the commit bit, at my suggestion, 
he fixed about 10 issues in a few months, and then disappeared and quit 
contributing.  To do tabbed windows, he must have made some preliminary 
changes that could have already been merged.  (Separate the editor 
window into a menu window and a frame.)  But no one else has yet dived 
into his tabbed window code to see if it is usable.  Mark Roseman also 
said he did the same but I have not seen his code either.

Part of the holdup is that the current class inheritance tree is wrong 
and needs to be refactored, without breaking things.

> 6) How to pass command line arguments when running a program.
>     (Yes, it's possible, but not intuitive to a beginner,
>      but much better than before)

There is nothing 'intuitive' about running an editor window as if the 
corresponding file had been run from a command line.  What we did is 
give people a partial command line for the part that comes after 'python 
-i <filename>'.  Should we say that on the form?

-- 
Terry Jan Reedy