[IPython-dev] IPython development: course adjustment required
fperez.net at gmail.com
Sun Jun 1 15:31:36 EDT 2008
On Sun, Jun 1, 2008 at 5:40 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 6/1/08, Fernando Perez <fperez.net at gmail.com> wrote:
>> So our current rethinking is: forge ahead with what we've been calling
>> IPython0, and begin integrating the various key (and functional)
>> components of IPython1 into it one by one. The IPython0/1 split will
>> end, and we will use all the good pieces of IPython1 to add
>> functionality to ip0 without losing its current features. At each 0.X
> This is definitely a good plan; even if porting of ipython0 code to
> ipython1 happened some day, the result would not be much "cleaner"
> than today's ipython0.
> Cleaning up ipython0's interfaces to allow inclusion of ipython1 is a
> better scheme overall; there are many places where obvious cleanups
> are possible (separation of input / output code etc), but have not
> been feasible because of "maintenance" status and small team - not to
> mention the questionable future. Essentially, creating an experimental
> branch of ipython0 where cleanups and ipython1 feature integration
> happens frees ipython0 from paralyzing conservativeness, and the
> development effort of everybody actually ends up in the hands of the
> end users.
I'm super happy to see everyone is so positive about the plan, and
thanks to all for the feedback. This response is an indicator (and a
lesson, at least to me) that the change was overdue :)
This new setup will let us all work with better integration towards a
common goal. I have urgent, immediate need of the ip1 features being
usable in production for research work at Berkeley, and I also want
things to be in good shape by the end of the summer: in the fall new
grad students arrive, and there are a number of interesting research
ideas that Brian and I want to push forward with that will require a
workable codebase for others to participate with.
Having the support of bzr will hopefully allow us to be flexible about
trying out small experimental side branches for new features with
regular merges, instead of the 'forever split' situation we were
So let's move on!
More information about the IPython-dev