[IPython-user] ipython1.frontend.input_state_manager questions

Brian Granger ellisonbg.net@gmail....
Thu Apr 3 11:55:52 CDT 2008


Barry,

Just a warning - I have not looked at the input_state_manager code
yet, but I have an idea of what it does.

>  I'm working through ipython1.frontend.input_state_manager and had a
>  couple of questions for whomever is behind it (and thanks for getting
>  started!)...
>
>  1. PendingResult sounds an aweful lot like a t.i.d.Deferred. I hope
>  we're not planning to reimplement Twisted ;)

So here is the story....the PendingResult object was created as a
deferred like thingy that has two important differences:

1) It works just fine in a process that doesn't have the twisted event
loop running - and that is using blocking sockets.

2) The PendingResult object has a blocking/polling interface that is
_very_ different from a deferred:

3) It doesn't have the sophisticated errback/callback chains.

pr = MethodThatReturnsAPendingResult()
pr.get_result(block=False)    # poll for result
pr.get_result(block=True)     # block for result

In a sense the PendingResult object is a compromise - most scientific
users would pass out of you told them they needed to learn about event
loops and deferreds to use ipython1.  But at the same time, ipython1
really is asynchronous and we can't completely hide that.  That was
the motivation - and no we definitely are not going to reinvent
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.).

Many times!  I just need to get someone to buy me an IPhone :)  I need
to write a grant for this maybe.

> 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)

I think your recommendation is a very good one.  Especially because it
will have it _much_ easier for people to subclass to customize how
given events are handled.

>  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?

Definitely a great idea.

>  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?

Absolutely there should be two different functions for this!

>  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).

Yep, the engine itself will raise a SyntaxError it the frontend sends
an incomplete block.


>  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)

Yes.  One thing to keep in mind is that Gael (who wrote the
input_state_manager) is very line oriented.  Fernando and I are much
more biased towards a block approach (our Mathematica heritage)  But,
I think we will end up with both line and block oriented frontends.
The input_state_manager either needs to be neutral on this issue, or
we need subclasses to implement the line/block approaches.

> 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).

This makes sense.

Feel free to make any changes to the input_state_manager that you want/need.

Brian

>  thanks!
>
>  Barry
>  _______________________________________________
>  IPython-user mailing list
>  IPython-user@scipy.org
>  http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>


More information about the IPython-user mailing list