The python readline.c is missing several of the API
funcs provided by libreadline. This patch adds the
missing ones that I needed.
Add support for libreadline callbacks to python functions.
eg:
readline.set_py_callback_hook( my_func )

Also, export rl_delete_text, rl_message,
rl_on_new_line, rl_forced_update_display,
rl_position_cursor

-Bruce

Logged In: YES 
user_id=21627

Have these function always been available in readline (i.e.
all readline versions)? If not, please provide configure.in
changes.

Also, please provide Doc/lib/libreadline.tex changes.

If you cannot provide these things, please indicate so.

Logged In: YES 
user_id=1251183

AFAIK, yes, they have always been available, at least in
Linux. I've been carrying this patch around since python 2.1.
I have not looked into this on other platforms.
I can't commit to providing doc changes. With my schedule,
it was all I could do to package it up and send it in. 
I'm sorry, I know this is incomplete work, but I figure
someone may be able to use it.

-Bruce

Logged In: YES 
user_id=21627

As incomplete work, we might have to reject it, unless
somebody volunteers to complete it. Let's give it one month
from now.

Logged In: YES 
user_id=1251183

I got the OK to work on the docs. Here's the patch
resubmitted with the libreadline.tex changes.

-Bruce

Logged In: YES 
user_id=6656

I've just broken this patch by changing the signature of the set_hook/
on_hook functions.

There seem to be some whitespace oddities (e.g. right at the start of the 
patch).

The docstrings should use the PyDoc_STRVAR macros.

I'm not sure about some of the details of the py_callback stuff (although 
the functionality seems desirable):

1) the name -- I think I'd find python_command more transparent
2) it would be nice to pass the count and key arguments to the Python 
callable
3) the comments around it's implementation don't make much sense to 
me.
4) the example in the docs -- which is what finally clued me in to what the 
function did :) -- isn't self-contained.

None of this should be very hard to deal with, but I don't know when/if I'd 
get round to it myself.

Access to rl_reset_line_state (and possibly others in the Redisplay
section) are also required, otherwise it's not possible to recover from
KeyboardInterrupt during raw_input() if readline isn't in the expected
editing mode.

Example:
  1. call raw_input() and use ctrl-R (reverse-i-search)
  2. catch a KeyboardInterrupt
  3. call raw_input() again

The input editing is still in reverse-i-search mode.
This makes it impractical to use raw_input() again after
KeyboardInterrupt because the input buffer may be in an unknown state.
If the history is modified then the search will break and character
input will appear to be ignored.

Note: It may be desirable to stay in this mode and call raw_input()
again, ignoring KeyboardInterrupt entirely (although the prompt is
redisplayed when exiting search mode so that doesn't currently work
cleanly), so it can't just auto-reset on KeyboardInterrupt.

The documentation should explain how to resume after KeyboardInterrupt
safely.

Issue1744456 contains a different patch to implement readline callbacks.  Suggest that anyone moving forward with this review both patches.

Simon: See Issue 24266 about recovering after interrupting the search mode.

Also, I think Issue 1744456 wraps a different part of the Readline API (rl_callback_ for non-blocking interface) to the patch here (rl_add_defun for adding a custom “key binding” or something). So the two patches could be considered independently.

rl_forced_update_display() wrappers already proposed in Issue 23067