[IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend
Fri Aug 8 11:50:12 CDT 2008
Unfortunately, today is the day that we are moving into our new place.
Thus, I will be mostly offline until early next week unless I can
sneak out to a coffee house some night. Fernando can help make any
decisions about how to proceed with the merges. Thanks again everyone
for helping out.
On Fri, Aug 8, 2008 at 9:57 AM, Barry Wark <email@example.com> wrote:
> On Fri, Aug 8, 2008 at 11:43 AM, Gael Varoquaux
> <firstname.lastname@example.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
> IPython-dev mailing list
More information about the IPython-dev