[IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend

[Barry Wark]

On Fri, Aug 8, 2008 at 11:43 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Fri, Aug 08, 2008 at 10:15:46AM -0400, Barry Wark wrote:
>> > Do you have a sense of how serious the conflicts are?  I've marked
>> > Gael's branch and my testing one 'for merge' so we can easily see the
>> > differences.
>
>> Besides trivial chanes (e.g. spliitting frontendbase into frontendbase
>> and asyncfrontendbase et al), the most significant diff between Gael's
>> branch and mine is that I've made the concept of an execution Block
>> more explicit. Instead of just an input string, a block is now an
>> object containing prompts, input and output as well as, possibly,
>> sub-blocks. The Block maps, conceptually, pretty directly to a
>> Mathematica notebook cell (you can see the Block definition in my
>> ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe
>> that the API for FrontEndBase can be made largely backwards
>> compatible, but some of the internal implementation must change to
>> support passing around Blocks instead of just strings.
>
>> OK, so I'd say the conflicts will not be too serious. They may be
>> serious enough to merge one at a time, especially working up to a
>> release. I'll hold off on my branch until things settle out from
>> Gael's merge.
>
>
> Barry, do you want check in access to my branch to implement these
> changes. I was waiting to add docstrings and tests before proposing this,
> but if you think you want to do this ASAP, I don't mind at all. I don't
> think I'll be able to merge before Sunday, though.

Thanks for the offer. I think making even relatively minor
architectural changes close before a release, while your code is still
under active development, and without *really* good test coverage is
dangerous. I'm not going to have time to give this the time it would
require before early next week when Fernando wants to push a release.
So I'd say the safest & best plan is to let you try to get your code
ready for release in time. I'll merge my changes in on the next dev
cycle.

>
> Gaël
>