[IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend

Barry Wark barrywark at gmail.com
Sun Aug 10 13:40:20 EDT 2008

On Sat, Aug 9, 2008 at 6:17 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> 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
>> this::
>>       try:
>>           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.
> Done.
>> 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.
> Done.
>> Configuration should be done using the approach in IPython.config.
>> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for
>> examples.
> 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
>> though.
> 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
>> asyncfrontend.py.
> Done. The methods grew organicaly from my needs to implement the
> front-end. And I suspect some more will come for some speicif needs.
>> asyncfrontendbase.py
>> ====================
>> 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.
> Done.
>> linefrontendbase.py
>> ===================
>> This looks good as it is simply a concrete subclass of FrontEndBase.
>> General comments above about docstrings apply.
> Done.
>> prefilterfrontend.py
>> ====================
>> 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
>>          repeated.
>>       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
> improved.
> Will now work on tests.
> Gaël
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev

More information about the IPython-dev mailing list