[IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend
Sun Aug 10 12:40:20 CDT 2008
On Sat, Aug 9, 2008 at 6:17 PM, Gael Varoquaux
> On Thu, Aug 07, 2008 at 11:11:00AM -0700, Brian Granger wrote:
>> We need a robust way for modules in the frontend to handle interfaces
>> if zope.interface is not installed. Currently each module tries to
>> import zope.interface and then builds a mock zope.interface, like
>> from zope.interface import Interface, Attribute, implements, classProvides
>> except ImportError:
>> Interface = object
>> def Attribute(name, doc): pass
>> def implements(interface): pass
>> def classProvides(interface): pass
>> This code should probably be put into a common location, something
>> like frontend.zopeinterface, so that it can be reused.
>> The docstrings are vague and outdated at points. More detailed and
>> updated docstrings would be helpful. Also, all docstrings should use
>> the epydoc+ReST format.
>> Configuration should be done using the approach in IPython.config.
>> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for
> I am not sure what you mean here. I don't see anything in the current
> IPython.kernel.config that is of direct use to the frontends. I do agree
> that in the long run we want to move to that, but right now I was more
> focussed on getting the frontend right, and punting on configuration. It
> can be added later when we are happy with one frontend at least, when the
> code is well documented and tested. I would say this is low priority.
>> IFrontEnd has references to Twisted in its docstrings. Because the
>> basic frontend should work without Twisted, the docstrings should be
>> updated to clarify how the interface plays with Twisted, even though
>> it is optional. We really want to document for developers that the
>> base frontend is synchronous and doesn't require Twisted, but that the
>> interface has a particular design that allows it to be wrapped into an
>> asynchronous frontend (like some methods pass through the result).
> Done. However, some methods in there do not make sens in a synchronous
> frontend (update_cell_prompt, add_block_id_for_result,
> add_block_id_for_failure, compile_ast). I suggest moving them in the
> asyncfrontend, as right now they are just making it hard for the
> developper to figure out what the core interface of a frontend is.
I disagree; they can make just as much sense in a synchronous frontend
as in an ansychronous one. If you chose not to use them in your
implementation, that's your choice as implementor.
>> The design of the frontend seems good though. We might eventually
>> want to think about using the notification stuff in the frontend
> Sure, we can talk about this at SciPy.
>> Why does FrontEndBase not have a complete method? Other frontend
>> classes do have this method and its seems like the base class should
>> have it too. Also, there are oher methods in the interpreter that we
>> might want to propagate up to the frontend, like push and pull.
>> Thoughts? If these additional methods go in, there should be separate
>> asynchronous versions that return deferreds, but these would go into
> Done. The methods grew organicaly from my needs to implement the
> front-end. And I suspect some more will come for some speicif needs.
>> Because this frontend us designed for use with Twisted, I don't think
>> we need to protect the zope.interface and Twisted imports. Also setting
>> Failure to Exception will break things as they don't have the same interface.
>> This looks good as it is simply a concrete subclass of FrontEndBase.
>> General comments above about docstrings apply.
>> It is fantastic that we can combine ipython0 and IPython.kernel.core
>> code like this. This is a great way of using the new stuff, but
>> getting the more complete feature set of IPython.* But I think this
>> type of thing should be done in the lower-level Interpreter, rather
>> than the frontend. This is for a couple of reasons:
>> 1. This would give all users of the Interpreter access to completion and the
>> prefilter stuff. We really need this stuff in the parallel
>> computing stuff,
>> as well as non-line-oriented frontends.
>> 2. The Interpreter already has some of this logic and it is simply being
>> 3. The current implementation requires that the Interpreter is in-process.
>> For connecting to a remote Interpreter, this won't work.
> I fully agree with you. I would even state that the way forward with this
> is to abstract out of IPlib the methods used in prefilter frontend, fix
> things that don't feel right with them (eg that some code is actual
> executed during the prefiltering), and move them out of this file, into
> the interpreter. This file should get thinner and thinner as we move
> forward, and eventually disappear. I see it as a way to transisition
> softly from ipython0 to ipython1. It is a stop-gap solution.
> By the way, I have just pushed a cleanup of my branch. I have added
> docstrings and reorganized the code. I'd be happy to have some feedback
> on where things are hard it understand and where names or docs could be
> Will now work on tests.
> IPython-dev mailing list
More information about the IPython-dev