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

[Brian Granger]

Hello all,

I picked a bad week to be away from email....

It is great to see that so many people are excited about pushing
ipython to the next level.  I have a number of comments about various
aspects of this:

Fernando:
> - We'll try to keep compatibility with existing APIs (like ipapi)
> where feasible, but there are no promises.  We'll break backwards
> compatibility wherever we need to in order to do the right thing.

I think this needs to be clarified.  The current ipython1 (purposely)
makes no attemps to be API compatible with the ipython trunk.  In
fact, I would say that in most cases it is _extremely_ different that
what is in ipython.  The reason for this is that the abstractions
needed in ipython1 are _extremely_ different that those in ipython
trunk.  Thus, the APIs are also very different.

Walter:
> Porting ipipe/ibrowse to ipython1 would be simple, once we have a
> display hook extension mechanism. Except for the hook that invokes the
> display object, there are no other dependencies.

I don't know much about ipipe, but in IPython1 there is no such thing
as a display hook - and there won't ever be - not in the same sense
that there is in ipython trunk.  I think we will be able to implement
ipipe in ipython1, but the implementation will look completely
different.  In particular, in ipython1, things are divided between the
"core" which knows nothing about how things are displayed and the
frontend, which makes all the display related decisions.  My feeling
is that ipipe will have to be implemented in the various frontends
rather than in the core.  This is good though as it will make it
possible to create nice GUI based ipipe widgets in the GUI frontends.
But it does mean that the implementation will look really different.

Ville:
> don't see why not. We can call both, because it is a priority to
> retain API compatibility with the trunk and the next-gen IPython
> (generics, hooks and ipapi are all part of the API).

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.

The important point is feature parity.  This is what I would say our
priority must be as we think about how ipython trunk and ipython1 will
be related.  But achieving feature parity in the context of a system
(ipython1) that has completely different abstractions will most
definitely require API changes.

This is why I think it will be important to have everyone hacking away
at ipython1.  There are a lot of basic design decisions/discussions
needed because things are so different.

To get ready for this, the best thing would be for everyone to begin
looking at the new core,

http://projects.scipy.org/ipython/ipython/browser/ipython1/trunk/ipython1/core

to see how things in ipython can be mapped onto ipython1.

Over the next few weeks, I am going to try to get ipython1 ready to
"have a party"

Cheers,

Brian