History stepping in interactive session?
A couple of weeks ago I posted a question on superuser.com about whether there is a way to get the same *very* convenient stepping-through-command-history behaviour in an interactive Python interpreter session as is possible in (at least) the bash shell with the Ctrl-o keybinding: http://superuser.com/questions/477997/key-binding-to-interactively-execute-c... I was spurred to ask this question by a painful development experience full of Up Up Up Up Up Enter Up Up Up Up Up Enter ... keypresses to repeat a previous set of Python commands/statements that weren't worth putting in a script file, or which I wanted to make very minor changes to on each iteration. As you might have noticed, I didn't get any answers, which either means that I'm the only person in the world to think this is an issue worth getting bothered about, or that there is no such behaviour available. Perhaps both -- but my feeling is that if this behaviour were available and well-known, it would become heavily used and very popular. As many other readline behaviours *do* work, this one would be really nice to have -- any chance that it could be added to a future release? (if it's not already there via some secret binding) Thanks! Andy
Andy Buckley writes:
A couple of weeks ago I posted a question on superuser.com
Maybe it's a bug. (See below.) Have you checked the tracker? Have you posted to python-list? That's a better place than here to get that kind of information.
As you might have noticed,
The people on this list (and on python-dev) probably don't pay much attention to questions on superuser.com, unless they're the kind of people who hang out on python-list. Sorry for not being much help, but after trying the obvious (read the GNU bash manpage, grep the output of "bind -p" to find out what C-o does, check that python does link to "True GNU" readline on my platform, try python, and when that didn't work, restart python after doing "bind -p >> ~/.inputc", which didn't work either), I don't know. It *might* be a bug, or you could file for an RFE if it's by design.
On 05/10/12 12:26, Stephen J. Turnbull wrote:
Andy Buckley writes:
A couple of weeks ago I posted a question on superuser.com
Maybe it's a bug. (See below.) Have you checked the tracker? Have you posted to python-list? That's a better place than here to get that kind of information.
As you might have noticed,
The people on this list (and on python-dev) probably don't pay much attention to questions on superuser.com, unless they're the kind of people who hang out on python-list.
Hi Stephen -- thanks for the feedback. I know StackExchange sites are not affiliated to the Python project! By "as you might have noticed" I didn't mean to imply that you spend your time scouring all Q&A sites for anything Python-related, but just that if you followed the link I posted you'd probably notice the zero response :)
From searching around before that SuperUser post, and some more afterwards, I couldn't find any reference at all to history-stepping as an available Python interpreter feature, so I was trying to suggest that as a new feature -- not a bug report. Sorry if python-ideas is only for language/stdlib features rather than the standard infrastructure.
However, I hadn't remembered when I first posted that I was already making use of a PYTHONSTARTUP script with the readline module to enable some history functionality -- I'd set that up years ago and ported it between systems. So my premise that readline *should* work was not accurate: sorry for the noise. Notably the operate-and-get-next readline function (thanks for the bind -p suggestion) bound to Ctrl-o does not work with Python readline... but I will follow up on that potential bug elsewhere. So one last question, in case it is an acceptable python-ideas topic: how about adding readline-like support by default in the interpreter? But maybe there is a reason for new users to have a more bare-bones, no-history introduction to the language, unless they start with ipython? Thanks again, Andy
On Sun, Oct 07, 2012 at 10:25:34PM +0200, Andy Buckley <andy@insectnation.org> wrote:
Sorry if python-ideas is only for language/stdlib features rather than the standard infrastructure.
readline is a Python module so ideas about it are certainly allowed here.
Notably the operate-and-get-next readline function (thanks for the bind -p suggestion) bound to Ctrl-o does not work with Python readline... but I will follow up on that potential bug elsewhere.
You probably need to reread the entire thread because the reason why it does not work with Python was already found and reported. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
Andy Buckley writes:
So one last question, in case it is an acceptable python-ideas topic: how about adding readline-like support by default in the interpreter?
If readline-like support is available on the system, it's used. However, it's apparently only readline-like. For example, on Mac OS X, the BSD-licensed libedit readline emulation is used by default, it appears. I wouldn't expect full functionality there. On GNU/Linux systems, as I wrote, True GNU readline is used. Why this particular function isn't bound or doesn't work right, I don't know offhand. It is apparently a bug (my Python sources are from April, but I can't see why this would change), since the sources say (ll. 927-931 of Modules/readline.c): /* Initialize (allows .inputrc to override) * * XXX: A bug in the readline-2.2 library causes a memory leak * inside this function. Nothing we can do about it. */ but even adding a binding to .inputrc doesn't work for me (Gentoo Linux). Bugs http://bugs.python.org/issue8492 http://bugs.python.org/issue5845 are related; I don't know whether it's worth filing an additional bug as I suspect it will get fixed in passing if 8492 is fixed.
On Mon, Oct 08, 2012 at 05:12:24PM +0900, Stephen J. Turnbull wrote:
Andy Buckley writes:
So one last question, in case it is an acceptable python-ideas topic: how about adding readline-like support by default in the interpreter?
If readline-like support is available on the system, it's used. However, it's apparently only readline-like. For example, on Mac OS X, the BSD-licensed libedit readline emulation is used by default, it appears. I wouldn't expect full functionality there.
On GNU/Linux systems, as I wrote, True GNU readline is used. Why this particular function isn't bound or doesn't work right, I don't know offhand. It is apparently a bug (my Python sources are from April, but I can't see why this would change), since the sources say (ll. 927-931 of Modules/readline.c):
I thought so too, but apparently the behaviour being talked about is a bash extension to readline. Adding it to Python would be a feature request, not a bug fix. While it's a useful feature, I think that it's probably something which can distinguish the vanilla Python interactive interpreter from more advanced environments like iPython, which apparently already has it. -- Steven
Steven D'Aprano writes:
I thought so too, but apparently the behaviour being talked about is a bash extension to readline. Adding it to Python would be a feature request, not a bug fix.
In that case, I think it's unfortunately that Python doesn't provide a way to warn about unimplemented stuff in .inputrc. Both on my Mac and on my Gentoo system, C-o simply does nothing.
On Mon, Oct 8, 2012 at 8:42 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Steven D'Aprano writes:
I thought so too, but apparently the behaviour being talked about is a bash extension to readline. Adding it to Python would be a feature request, not a bug fix.
In that case, I think it's unfortunately that Python doesn't provide a way to warn about unimplemented stuff in .inputrc. Both on my Mac and on my Gentoo system, C-o simply does nothing.
Please do file a bug about this. Python's interface to readline is pretty old, I wouldn't be surprised if more functionality could be added. Regarding operate-and-get-next, I searched for "gnu readline operate-and-get-next" and found some feature requests about it for Sage and IPython (not sure of the status there), plus an explanation of why it's not part of GNU readline: it needs to be implemented by the calling app because only the latter knows what constitutes a complete statement. I think either of these would probably be a fun project for an aspiring core developer interested in improving their C skills. -- --Guido van Rossum (python.org/~guido)
On Mon, Oct 08, 2012 at 09:13:58PM -0700, Guido van Rossum wrote:
On Mon, Oct 8, 2012 at 8:42 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Steven D'Aprano writes:
I thought so too, but apparently the behaviour being talked about is a bash extension to readline. Adding it to Python would be a feature request, not a bug fix.
In that case, I think it's unfortunately that Python doesn't provide a way to warn about unimplemented stuff in .inputrc. Both on my Mac and on my Gentoo system, C-o simply does nothing.
Please do file a bug about this. Python's interface to readline is pretty old, I wouldn't be surprised if more functionality could be added.
The time machine strikes again: http://bugs.python.org/issue8492 -- Steven
On Fri, 05 Oct 2012 11:27:28 +0200 Andy Buckley <andy@insectnation.org> wrote:
A couple of weeks ago I posted a question on superuser.com about whether there is a way to get the same *very* convenient stepping-through-command-history behaviour in an interactive Python interpreter session as is possible in (at least) the bash shell with the Ctrl-o keybinding:
The interactive interpreter (and I mean the default one, not third-party choices like IPython) uses libreadline for its editing and history functionality, so it's really a question about libreadline you're asking. I don't know if it allows such customization, but perhaps the Web site has the answer you're looking for: http://www.gnu.org/software/readline/ http://cnswww.cns.cwru.edu/php/chet/readline/rluserman.html Regards Antoine. -- Software development and contracting: http://pro.pitrou.net
On Fri, Oct 05, 2012 at 02:09:27PM +0200, Antoine Pitrou <solipsis@pitrou.net> wrote:
The manual lacks the function "operate-and-get-next" bound in bash to Ctrl-O. Either the manual is old or the function is not a function of readline but rather one implemented by bash. That requires further investigation (which I'm not going to do). Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Fri, Oct 5, 2012 at 3:17 PM, Oleg Broytman <phd@phdru.name> wrote:
On Fri, Oct 05, 2012 at 02:09:27PM +0200, Antoine Pitrou <solipsis@pitrou.net> wrote:
The manual lacks the function "operate-and-get-next" bound in bash to Ctrl-O. Either the manual is old or the function is not a function of readline but rather one implemented by bash. That requires further investigation (which I'm not going to do).
The function is implemented by bash; see operate_and_get_next() in bashline.c. -Nadeem
On Fri, Oct 05, 2012 at 05:23:08PM +0200, Nadeem Vawda <nadeem.vawda@gmail.com> wrote:
On Fri, Oct 5, 2012 at 3:17 PM, Oleg Broytman <phd@phdru.name> wrote:
On Fri, Oct 05, 2012 at 02:09:27PM +0200, Antoine Pitrou <solipsis@pitrou.net> wrote:
The manual lacks the function "operate-and-get-next" bound in bash to Ctrl-O. Either the manual is old or the function is not a function of readline but rather one implemented by bash. That requires further investigation (which I'm not going to do).
The function is implemented by bash; see operate_and_get_next() in bashline.c.
Thanks! That closes the issue -- the function are to be implemented by (a user of) Python if one wants to have it in Python. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On 05/10/12 22:09, Antoine Pitrou wrote:
On Fri, 05 Oct 2012 11:27:28 +0200 Andy Buckley<andy@insectnation.org> wrote:
A couple of weeks ago I posted a question on superuser.com about whether there is a way to get the same *very* convenient stepping-through-command-history behaviour in an interactive Python interpreter session as is possible in (at least) the bash shell with the Ctrl-o keybinding:
The interactive interpreter (and I mean the default one, not third-party choices like IPython) uses libreadline for its editing and history functionality, so it's really a question about libreadline you're asking.
I don't think so. I'm not an expert on readline, but it seems to me to be a Python bug. In bash, I check for the existence of the "operate-and-get-next" command, and sure enough it is bound to C-o (Ctrl-o) as expected: [steve@ando ~]$ bind -p | grep operate "\C-o": operate-and-get-next I don't believe that there is any direct mechanism for querying the current readline bindings in Python, but I can fake it with the "dump-functions" command: import readline readline.parse_and_bind(r'"\C-xd": dump-functions') If I then type Ctrl-x d at the interactive interpreter, readline dumps the function bindings to screen: py> readline.parse_and_bind(r'"\C-xd": dump-functions') py> abort can be found on "\C-g", "\C-x\C-g", "\M-\C-g". accept-line can be found on "\C-j", "\C-m". arrow-key-prefix is not bound to any keys backward-byte is not bound to any keys backward-char can be found on "\C-b", "\M-OD", "\M-[D". [...] operate-and-get-next is absent from the list. I don't mean that it is not bound. It just isn't there at all. If I nevertheless try to use it: readline.parse_and_bind(r'"\C-o": operate-and-get-next') it does *not* enable Ctrl-o as expected, operate-and-get-next remains absent from the list of bindings. I have checked this on both Python 2.7 and 3.3.0rc3 under Centos 5, and on 3.3.0rc3 under Debian Squeeze. -- Steven
On Sat, 06 Oct 2012 00:24:39 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
On 05/10/12 22:09, Antoine Pitrou wrote:
On Fri, 05 Oct 2012 11:27:28 +0200 Andy Buckley<andy@insectnation.org> wrote:
A couple of weeks ago I posted a question on superuser.com about whether there is a way to get the same *very* convenient stepping-through-command-history behaviour in an interactive Python interpreter session as is possible in (at least) the bash shell with the Ctrl-o keybinding:
The interactive interpreter (and I mean the default one, not third-party choices like IPython) uses libreadline for its editing and history functionality, so it's really a question about libreadline you're asking.
I don't think so. I'm not an expert on readline, but it seems to me to be a Python bug. [snip useful explanations]
Well, if there is a bug, then it should be reported on the tracker (and a patch uploaded, if possible :-)). Regards Antoine. -- Software development and contracting: http://pro.pitrou.net
Over on python-ideas, a question about readline was raised and, I think, resolved. But while investigating the question, it became obvious to me that the ability to inspect the current readline bindings from Python was both useful and important. I wrote:
I don't believe that there is any direct mechanism for querying the current readline bindings in Python,
But it was requested some time ago: http://bugs.python.org/issue8492 Is there anyone willing and able to give this issue some attention please? (Replies to python-dev only please.) -- Steven
On 5 October 2012 10:27, Andy Buckley <andy@insectnation.org> wrote:
A couple of weeks ago I posted a question on superuser.com about whether there is a way to get the same *very* convenient stepping-through-command-history behaviour in an interactive Python interpreter session as is possible in (at least) the bash shell with the Ctrl-o keybinding:
http://superuser.com/questions/477997/key-binding-to-interactively-execute-c...
I was spurred to ask this question by a painful development experience full of Up Up Up Up Up Enter Up Up Up Up Up Enter ... keypresses to repeat a previous set of Python commands/statements that weren't worth putting in a script file, or which I wanted to make very minor changes to on each iteration.
As soon as I find myself doing this I quit the interpreter and start ipython. The feature that ipython has that makes what you are doing much easier is the magic %edit command. Just type In [1]: edit tmp.py and your favourite editor will open up allowing you to write/edit some code. When you close the editor, ipython will run the code from tmp.py within the interactive session (as if you had typed it in directly). If you want to rerun that code with modifications just type 'edit tmp.py' again and you can make the modifications within your editor. Oscar
On 10/5/2012 8:43 AM, Oscar Benjamin wrote:
On 5 October 2012 10:27, Andy Buckley <andy@insectnation.org> wrote:
I was spurred to ask this question by a painful development experience full of Up Up Up Up Up Enter Up Up Up Up Up Enter ... keypresses to repeat a previous set of Python commands/statements that weren't worth putting in a script file, or which I wanted to make very minor changes to on each iteration.
Using Windows for a couple of decades, I am not spoiled by bash ;-). Idle lets me directly click on a previous statement and hit enter to make it the current statement. Edit if desired and hit enter again to execute again in the current workspace. But I agree with Oscar that even a few lines are worth a temporary script file.
As soon as I find myself doing this I quit the interpreter and start ipython. The feature that ipython has that makes what you are doing much easier is the magic %edit command. Just type
In [1]: edit tmp.py
and your favourite editor will open up allowing you to write/edit some code. When you close the editor, ipython will run the code from tmp.py within the interactive session (as if you had typed it in directly). If you want to rerun that code with modifications just type 'edit tmp.py' again and you can make the modifications within your editor.
In Idle, I click File - Recent files - .../tem.py (in my misc. files directory) to open an edit window, which I leave open all day. Running from the edit window does restart the workspace, so one would have to cut and paste to not restart. I seldom want to re-run multiple lines without restarting. If I want to keep the 'temporary' code, saving under a different name is easy. -- Terry Jan Reedy
participants (9)
-
Andy Buckley -
Antoine Pitrou -
Guido van Rossum -
Nadeem Vawda -
Oleg Broytman -
Oscar Benjamin -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy