[IPython-dev] [IPython-user] Development plans update

[Ville M. Vainio]

On Feb 2, 2008 1:04 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> 2.  Prompt display.  IPython prompts can include info from the users namespace.

I think the prompt calculation should be done in the back-end. Isn't
it trivial for the frontend to ask for the prompt string from the back
end (even if it doesn't happen by merely writing out the characters)?

> 3.  Traceback printing.  Tracebacks are formatted (ACSII coloring,
> etc) by ipython at the moment the exception is raised, when the full
> state of the interpreter is available to look at.

Why can't the back end just render the exception string, and let the
display be handled by front end? We can change the color escape
sequences to something more "universal", if need be (<red>foo</red>,
<highlight>NOTE</highlight>, whatever).

> whatever way is best.  While this doesn't look too bad there is a lot
> of subtlety going on underneath the hood.  For example, the complete
> method could actually trigger a network call to ipython core/engine
> running on a remote system.  At the time the complete call gets made,
> the engine could be executing some blocking C code the user had
> started in a previous line.  In this case, the tab completion can't
> happen until that C code finishes (threads won't help).  So, then, in
> a case like that, the complete method will need to raise an exception
> to reflect the fact that TAB completion can't happen right now.

If we have the part that communicates with the front end in a separate
thread, this won't be a problem. Completion can ALWAYS happen. This is
probably easy stuff, apart from ctrl+c handling.

> Prompts.  If a frontend wants a prompt to include information from an
> object in the users namespace, the frontend will have to get the
> object (over the network possibly) each time it wants to update the
> information:
>
> a = interpreter.pull('a')
>
> This gets the object named 'a' from the users namespace.  Again, this
> can potentially be a non-local (network) call, that is not completed
> immediately.

If we ask for the whole prompt from the back end, we know when it will
be fully ready. Here, the complications are in the front end.

> Displaying things.  The core of ipython1 will not be able to make any
> decisions about how things (stdout, tracebacks, etc) are formatted.
> This is because a single instance of the core could be simultaneously
> connected to frontends that need things formatted in completely
> different ways.  You could have a Javascript frontend, a terminal
> based frontend and a Qt app all talking to the same instance of the
> core.  Because of this, the core will need to return output in a
> "unformatted format." (xml, python dict, etc)  that can transformed by
> the frontends into whatever form they need.

Yeah, this is what I referred to earlier. Changing what the back end
blurts out to xml should be pretty easy, and a trivial front end
implementation (a readline one) can just do string replace to convert
it to the current ansi codes.

> to varous methods of the interpreter.  This is what I mean that the
> "core" won't know anything about display hooks.  They will still
> exist, but look very different.

I think the display hooks should still be in core, but return strings
instead of direct printing.

> Does this help give a better idea about why the APIs will look so different?

Yes. Meetings these expectations seems like a pretty fun project, though :-)

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'