[Python-ideas] Option of running shell/console commands inside the REPL

[Terry Reedy]

On 2/2/2019 8:13 AM, Oleg Broytman wrote:
> On Fri, Feb 01, 2019 at 08:40:22PM -0500, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 2/1/2019 3:31 PM, Oleg Broytman wrote:
>>
>>> Python REPL is missing the following batteries:
>>
>> That is why, on Windows, I nearly always use IDLE.

I believe this was Chris, not me.

>>
>>> * Persistent history;
>>
>> IDLE's Shell history persists across restarts (which
>> are not available is the standard shell).  I cannot remember wanting history
>> saved between IDLE sessions.  I also cannot remember seeing a request for
>> this feature.  If I want a sequence of commands saved, I copy them into an
>> editor window and save in a named file.
>>
>>> * Syntax highlighting;

To do this correctly requires a separate programmable repl that sees 
each character as it is entered.  To me, this is as useful in the repl 
as in an editor.

>> IDLE does this.
>>
>>> * Clear separation (using, for example, different colors)
>>>     between input, output and errors;
>>
>> IDLE does this.
> 
>     For the question "Does Python REPL need more batteries?" is your
> answer "No, just point people to IDLE"?

If one want these batteries *today*, that is one sane answer, especially 
on Windows and, it seems so far, Mac.

>     If it is - well, I disagree. I implemented a lot of enhancements for
> REPL myself, and I don't like and avoid GUI programs.

Whereas, in spite of (or perhaps because of) possibly being older than 
you, I am the opposite.  Many beginners, even after multiple college CS 
classes, have never used a TUI (text user interface) program like 
Command Prompt before encountering Python and wanting to do something 
that requires the TUI, such as using pip.

Anti-GUI attitudes make Python harder to use for many people.  Pip, for 
instance, desperately needs a GUI front end.  I believe that PIP 
problems are the most common Python question on StackOverflow.  However, 
the pip people will not write one and I was prohibited from adding one 
to the stdlib.

>>> * Paging of very long output/errors.
>>
>> Help output *is* paged in the standard shell.  For comparison with IDLE, for
>> issue 35855, I tried out help(tkinter) in standard Python on both Windows
>> and Mac.  For the most part, I found the pagers to be somewhat obnoxious and
>> deficient*.  Except for one thing that I want to fix, paging up and down a
>> window with the standard PageUp and PageDown keys, as in IDLE, is easier and
>> better.  And it is not limited
> 
>     I found pager ``less`` quite good. I configured it in a complex way,
> learned to use it and use in many different programs, not only Python.
> 
>> * Windows Console holds a maximum of 9999 characters, with the default being
>> 300, at least for Command Prompt.  The less pager, at least on Mac, when
>> invoked by help when running Python in Terminal, displays the paged output
>> in a separate window.  When less is exited, the window closes and the paged
>> output *disappears*.

I don't know what less configuration one can do on Mac, but its default 
of erasing help output before one writes the statement one wanted help 
for is quite bad to me.

> You left out what I think is a very important 'battery':
>> * Works with Python statements instead of physical lines of text.
>> As I discussed elsewhere, this includes editing entire multiline statements
>> before submitting and storing and retrieving complete statements to and from
>> the history list.
> 
>     Yep, would be nice to have. Bash implements it somehow.

Mac terminal does not.

>> Here is another:
>> * Clicking on a traceback item can open the file in an editor at the
>> indicated line.
> 
>     That would be too much.

Now that I am used to this, I consider it essential.

> Requires a traceback-sensitive pager.

It require something that can match the regex "File ([~,]*), line 
([0-9]*)," to a selected line or the one above it and pass the captured 
file name and line number (if successful) to something that can open the 
file at the line).

> Also
> not very useful for situations where developer works on one host and
> runs programs on another (containers/virtual machines/remote hosts are
> widely used these days).

I and many other people edit and run on the same machine.  However, 
editing and running on different machines is to me an argument for 
keeping the UI separate from the execution binary.  What matters is 
where the user interface presenting the traceback is, not where the 
program was run. IDLE runs user code in a separate process, with a 
socket and rpc connection to the GUI.  It could potentially run the 
separate process in a separate machine.

IDLE compiles user code in the GUI before sending the code object to the 
execution process.  The 'instant' syntax check would be even more 
relatively useful if execution were on a remote machine, with the 
attendant delay.

Another IDLE feature I miss in the default REPL is smart 
auto-indentation.  This includes following some PEP 8 recommendations 
for non-significant indentation of continuation lines.

Thinking about it, the IDLE code either is or could be independent of 
the tkinter text widget.  With a little work, it could be moved into the 
code module for use by InteractiveInterpreter, which IDLE uses, and by 
anyone else, including, maybe, python itself.  Since it enforces a 
particular style, it would have to be optional at least for 
InteractiveInterpreter and python.

-- 
Terry Jan Reedy