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

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


> 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