[IPython-user] ipython1.frontend.input_state_manager questions

Barry Wark barrywark@gmail....
Thu Apr 3 09:57:34 CDT 2008

Hi all,

I'm working through ipython1.frontend.input_state_manager and had a
couple of questions for whomever is behind it (and thanks for getting

1. PendingResult sounds an aweful lot like a t.i.d.Deferred. I hope
we're not planning to reimplement Twisted ;)

2. InputStateManager.process_key seems like it's going to get pretty
hairy if we try to abstract all key events _plus_ all other type of
input events that a frontend might use (such as mouse/gesture events
(oh, come on, you can't tell me you haven't thought of an iPhone
frontend for a distributed ipython1 cluster) etc.). Might it be more
sane to implement methods for each type of _event_ in
InputStateManager, such as, e.g.,
  key_down(unicode character) #insert a character
  history_navigation({up|down}) #move history
  insert_newline #send block to engine if complete (return True/False
to indicate sent to engine/continue)
  complete #e.g. tab or esc (different frontends may have different
completion gestures)

Of course this is off the top of my head. A strategy like this gives
the front ends more leeway to implement the appropriate input gestures
for their platform and then translate these gestures to
InputStateManager events. What do you think?

3. InputStateManager.push_text seems to be slightly confusing in
purpose, as did feed_block in the current ipython. It does two very
different things... submits a code block to the interpreter and
returns the result, or returns "\n" to indicate the block is
incomplete. Huh? Shouldn't there be two functions? One to help the
frontend handle continuations of an input block (this is already in
code_hasher.wants_more_lines) and a function to submit the block to
the controller, keeping track of history etc.? As a front end writer,
push_text feels too, well, pushy in the workflow it dictates. I would
think that push_text should raise an exception if the block is not
complete (i.e. it's the frontend's responsibility to make sure the
block is complete somehow before submitting it).

4. InputStateManager appears to want to maintain its own line buffer
(e.g. get_current_word refers to self.line). Is that correct? This may
be a pain for some front ends depending on whether (1) they represent
the lines as string buffers (e.g. a graphical, block programming front
end may not) or (2) the frontend's buffer can be easily bridged to a
python string. I think the pattern suggested by process_key is better
(i.e. the frontend passes the buffer and position to all methods).



More information about the IPython-user mailing list