[IPython-user] ipython1.frontend status

Brian Granger ellisonbg.net@gmail....
Thu Jun 5 10:11:53 CDT 2008


> 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.

> 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?

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.

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