[IPython-user] ipython1.frontend status
Thu Jun 5 10:57:27 CDT 2008
On Thu, Jun 5, 2008 at 8:11 AM, Brian Granger <firstname.lastname@example.org> wrote:
>> Following discussion of the last couple days, I thought I'd update
>> folks on the status of ipython1.frontend in the ipython1-cocoa branch.
>> I've made a first stab at the frontend.frontendbase module and have
>> implemented a bare-bones Cocoa frontend for ipython1. I subclassed
>> Cocoa's text view widget (well, actually I wrote a delegate for the
>> NSTextView, but it could have been done as a subclass) and also
>> subclassed frontend.frontendbase.FrontEndBase. Besides the code to
>> handle the appropriate events/text layout etc. which are specific to
>> Cocoa, my Cocoa frontend required about 200 lines of code. I think
>> it's a pretty good start for similar endeavors in Qt or Wx etc.
> Thanks for the update. In the next few days, I will begin to merge
> ipython1 -> IPython. To get ready for this, could you merge your
> cocoa branch into ipython1-dev? At least for the near future, I would
> like ipython1-dev to be the staging ground for things about to get
> pulled into IPython trunk. Once you feel like the frontend and cocoa
> stuff is stable enough (tests, docs, etc.) I would like to get this
> into IPython for people to begin playing with.
Yes. I will merge it in as soon as the tests and docs are in good shape.
>> One issue that's come up is that the deferred result
>> ipython1.kernel.engineservice.EngineService.execute has a string
>> representation of the block's output (in result['display']['pprint']),
>> but there's no way to get the actual python object that generated that
>> string. This prevents the frontend from e.g. rendering an image result
>> inline. I realize this is because the engine may be remote, but in the
>> case of (1) serializeable objects or (2) local engines, it seems that
>> we might want to add an option to execute to return the actual result
>> as well as its pprint/repr...
> I am not sure what you mean by "the python object that generated the
> string." Isn't the contents of the string, just stdout? If that is
> the case, then this python object doesn't even exist. Am I missing
Something like this:
The result of executing this block is a matplotlib figure (or a
lines.Line2D object, whatever). Wouldn't it be cool if the result the
frontend got back from the engine contained a reference to that figure
rather than just ""[<matplotlib.lines.Line2D object at 0x15b674d0>]"
or whatever its repr is? That way it could be rendered in-line, ala
Mathematica's Plot function output.
I realize there are thorny issues here... like side effects that you
mention below. Even worse than files may be graphical side effects
(what do you do with matplotlib.pyplot.show(), for example)?
> But, you bring up a very important and dificult issue - how to handle
> side effects (like an image being written to a file) of a execute
> statement. We have talked about this before and honestly, it is a
> really difficult problem. There are a couple of options we have
> 1) Have the core simply watch the cwd for new files and automatically
> bring those back (serialized) with the result.
> 2) Provide an API that user code can call into to declare the side
> effects that should be brought back with the result. This would lead
> to user code that looks like:
> from IPython.core import declare_file
> 3) Other crazy ideas that Fernando and Min will hopefully remember
> better than myself.
> But, this area is wide open for someone to step in and begin trying
> things. Once the ipython1->IPython merge has taken place, these
> things can be played with in IPython proper.
Cool. Should be fun.
>> IPython-user mailing list
More information about the IPython-user