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
_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev
