On 2/2/2019 8:13 AM, Oleg Broytman wrote:
On Fri, Feb 01, 2019 at 08:40:22PM -0500, Terry Reedy
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