[Python-ideas] Option of running shell/console commands inside the REPL
Steven D'Aprano
steve at pearwood.info
Sun Feb 3 06:24:12 EST 2019
On Sat, Feb 02, 2019 at 07:37:56PM -0500, Terry Reedy wrote:
[...]
> >>>* 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.
That's an ambiguous sentence. It could mean that syntax highlighting in
both are as useful as a screen door on a submarine :-)
I don't know how you use the REPL, but for me, highlighting in the REPL
is much less useful because I'm not looking at large chunks of code at
a time. If it is more than, oh, two or three lines, it is too big to be
editing in the clunky editing environment of a REPL and I'll use an
editor to read/edit the code.
> 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.
Did you put it on PyPI? That's the usual suggestion for something that
might be useful but isn't believed to be needed for the stdlib. As Nick
said,
Rather than "rejected" per se, I've closed this as "postponed"
https://bugs.python.org/issue27051#msg286634
https://summerofcode.withgoogle.com/archive/2016/projects/5063140450500608/
[...]
> 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.
I'd like to see the help pager code made into a public API, and help
itself made configurable by the user to choose a pager (auto-detecting a
pager by default, as it does now). That would allow people to choose
whichever pager works best for them -- possibly including a seperate GUI
window which they could leave open all the time.
> >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.
If you are running a sufficiently recent bash and readline is supported,
it should support any feature the POSIX bash supports, regardless of the
OS or the terminal.
(Although I think readline on Mac is slightly different from other Unix
systems? And maybe less functional?)
I'm not sure what multiline editing is being referred to above. I
personally don't know of one in bash. It may be that you have to turn
the feature on -- by default, bash ships with a fair amount of stuff
turned off, and the rest hidden behind cryptic keystroke commands.
One readline feature I know of which I would love to see supported in
the REPL is the "execute and next line" command. On my bash system, it
is Ctrl-O. What it does:
- use the up-arrow to move through the history to the line you
want to execute;
- type Ctrl-O to execute that line;
- the *next* line is automatically loaded, ready to be executed.
E.g. suppose my history consists of five lines:
1: print('hello')
2: def spam():
3: x = 1
4: return x + 1
5: foo = spam()
and I want to re-load the spam function (perhaps after editing it) in
the REPL. From a bare prompt, I can:
* hit UP-ARROW four times to get to line 2 of the history, then ENTER;
* this pushes a new line into the history;
* hit UP-ARROW four times again to get to line 3, then ENTER;
* hit UP-ARROW four more times to get to line 4, then ENTER.
With execute-and-next-line, I could:
* hit UP-ARROW four times to get to line 2 of the history, then Ctrl-O;
* this loads line 3, so I can immediately hit Ctrl-O;
* this loads line 4, so I can immediately hit ENTER.
Much easier to re-execute or edit a multiline block!
As far as I can tell, it is impossible to add this feature to the
REPL from pure Python (corrections welcome!) but I imagine it
would be something IDLE could do.
--
Steve
More information about the Python-ideas
mailing list