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

[Brian Granger]

> > I think to say that with ipython1 "it is a priority to retain API
> > compatibility with the trunk" is a misinterpretation of Fernando's
> > earlier statement.  Many things in the ipython trunk API are by
> > definition impossible to carry over the ipython1 because the
> > assumptions and abstractions are so different.  Of course, where we
> > can we will try to maintain API compatibility, but I think those cases
> > will be few and far between.
>
> Why are they so different?

Good question

One of the core assumptions in ipython trunk is that the frontend
(stdout/stdin/terminal/readline/etc) has full immediate and complete
access to things living in the users namespace.  A few examples:

1.  Tab complettion.  Readline detects a tab and calls the tab
completion machinery which directly looks at things in the users
namespace.

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

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.

This is the main assumption that gets broken in ipython1.  In
ipython1, the frontend has no direct access to anything in the user's
namespace.  Instead the frontend only has access to a standardized API
(methods, not attributes).  A perfect example is Tab completion.  Here
is how it will work with ipython1.

Let's say a user types the following:

In [1]: foo.     # and then hits TAB

When the frontend detects the TAB event, it will read the current
input as a string "foo."  It will then do something like:

interpreter.complete("foo.")

This will return a list of strings that are the possible completions.
It will then be up to the frontend to display those completions in
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.

Summary, TAB completion is still possible, but the API/design will
look completely different.  More specifically the functionality will
need to be decomposed into 1) a python method that encapsulates the
core behavior and and can happen over a network 2) the frontend code
that calls that method and the appropriate time and displays the
result.

Another example:

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.

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.

Because of this, the various parts of ipython that make decisions
about formatting will need to be moved to the frontend and hooked up
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.

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

Brian



> trunk/ is like the core, and a frontend will just manage the read /
> display functionality.
>
> If we just change all the printing to be some "write" function that
> can dump stuff to frontend, and raw_input to get stuff from front end,
> what else is different?