[IPython-user] ipython1.frontend status

Barry Wark barrywark@gmail....
Thu Jun 5 10:57:27 CDT 2008

On Thu, Jun 5, 2008 at 8:11 AM, Brian Granger <ellisonbg.net@gmail.com> 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?

Something like this:

>>> matplotlib.pyplot.plot([1,2,3])

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
> considered:
> 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:
> write_my_image('myfile.jpg')
> from IPython.core import declare_file
> declare_file('myfile.jpg')
> 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.

> Brian
>> Barry
>> _______________________________________________
>> IPython-user mailing list
>> IPython-user@scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user

More information about the IPython-user mailing list