readline-like behavior inside Twisted (was Re: [Twisted-Python] Re: Synchronization techniques)

Jean-Paul Calderone exarkun at divmod.com
Sun Apr 8 10:51:25 EDT 2007


On Fri, 06 Apr 2007 21:28:49 -0000, glyph at divmod.com wrote:
>On 06:18 pm, list-ener at strank.info wrote:
>>on 04.04.2007 23:40 glyph at divmod.com said the following:
>><snip>
>
>>>Run "python -m twisted/conch/stdio" for an example of an interactive
><snip>
>>>Here's a screenshot of an interactive session using the command above:
>
>>Am I right that this is a screenshot of the manhole client?
>
>Sort of.  It's the manhole server (I don't know what you mean by "client") 
>running on standard IO, run via 'python -m twisted/conch/stdio'.
>>For embedding this in twisted, the twisted reactor needs to be the one 
>>calling IPython/pyreadline when necessary.
>>On the IPython level, I think this should be "easy" by subclassing the 
>>Shell and splitting/rearranging the relevant code, so that it can be called 
>>back at the point where raw_input would normally return.
>>(I did not look at the new IPython saw branch...)
>
>>On the twisted side, I think that something like twisted.internet.stdio 
>>would be calling back?
>
>Rather than IPython calling into raw_input, the loop that calls raw_input 
>would have to be changed to a function that takes a string. This would 
>almost certainly be the trickiest part, since it seems there are about two 
>dozen places (at a quick glance) in ipython that call raw_input.
>>Or rather something like twisted.conch.insults?
>
>insults will be getting its events from twisted.internet.stdio, so both will 
>be involved.
>>I suspect that it would be hard to recode pyreadline in a way that it could 
>>be called back by twisted?
>>So to get readline support, something like readline would need to be 
>>implemented using t.i.stdio / insults.
>>
>>Does this seem possible, so far? :-)
>
>To me, sure - although I hardly have the time to do it :).  There have been 
>a few forays into line-editing code for insults, although I'm not clear of 
>the current state of the art, JP Calderone should be returning from vacation 
>soon and will probably have some light to shed on the issue.  I don't know 
>much about pyreadline.  There may be code there that's reusable, maybe not, 
>but in any event it is a goal of the insults library to provide high-quality 
>event-driven line-editing.
>

I haven't looked at pyreadline before, although I did take a look at UNC a
long time ago.  Taking a quick look at the code, it looks like converting
pyreadline to be Twisted friendly may be doable.  The most obvious change
that would be required is for each point in the code which calls getkeypress
or getchar to be changed to instead respond to an event.  The ideal way to
do this would be with a nice state machine which accounts for all the legal
inputs and states the input system can be in.  A slightly less nice way which
would probably be much easier to implement would be to add getkeypress and
getchar implementations which return Deferreds and then use inlineCallbacks
to avoid having to make significant changes to any of the callers.  This is
worse since it leaves the code a bit of a mess, but it might be useful as an
experiment.

As for insults, I expect it has a less complete implementation of all of the
typical readline features you or your users are interested in, but it is
gradually improving.  What would actually be really excellent is if both
insults and pyreadline used the same underlying readline model code which
was devoid of input/output code, then each could focus on the part it should
really care about (dealing with events or talking to a windows console or
what have you) and improvements to the actually interesting behavior in the
readline model could be shared between the two.

To some extend insults already has this (I've tried to factor as much of the
interesting behavior out away from the Twisted parts), and I see this is also
how at least some of pyreadline is structured (eg lineeditor/history.py), so
it might actually be feasible to merge the two backends into one shared
thing.

Jean-Paul




More information about the Twisted-Python mailing list