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

[Barry Wark]

On Thu, Aug 7, 2008 at 3:18 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi Brian,
>
> Thanks a lot for your comments, they are very valuable.
>
> I have to run to catch Stéfan at the airport, I just wanted to give an
> informal overview of the status of my work. I am currently battling with
> subprocess execution, including under windows. The hard stuff is the
> stdin capture, and it happens more often than I would like. Once I am
> done with that (hopefully today, though my afternoon will be busy working
> with Stéfan), I have to make sure that 'Ctrl-C' stops Python execution,
> which should be easy. After this I was planning to clean up the code, add
> comments and ask for merge.
>
> All your comments are very much to the points. Some of them where already
> on my todo list. Can you prioritize them, and tell me at which point I
> should do the merge. I also would like to merge ASAP, I just don't want
> to have bad crashers in the code before I merge (but if you think it is
> acceptable, I'll go for it), and I want to refactor some names and
> interfaces before the merge. Hopefully merge is a few work days away. Is
> that good enough, or should I try to get this done faster?
>
> Obviously this is a first cut, and there will be some lessons to learn.
>
>> 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.  But eventually
>> when
>> IPython.core is created, this should probably be moved there.
>
> Sounds good.
>
>> 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.
>
> Oh yes, definitely. The docstring are not good enough, and some of the
> names are not explicite enough.
>
>> IPython.kernel.core should probably be moved to IPython.core.
>
>> Once Fernando's testing branch has been merged, more tests should be written.
>
> +1. My stuff is hard to test, but I want to have a go and see what I can
> do.

Please, please have (near) complete test coverage for your work. It
will be infinitely harder to make the (likely) needed refactorings in
the future if we can't test easily. I've been working on several
changes to the internal working of FrontEndBase to make notebook-style
interfaces more natural and think that I can keep backwards compatible
API, but the implementation may change. Complete test will make
integrating those changes much easier.

>
>> frontendbase.py
>> ===============
>
>> Configuration should be done using the approach in IPython.config.
>> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for
>> examples.
>
> OK.
>
>> 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).
>
>> The design of the frontend seems good though.  We might eventually
>> want to think about using the notification stuff in the frontend
>> though.
>
>> 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.
>
> I need to come back on all this and define the interfaces in a more
> formal way. Currently this is messy, and I have been coding the frontend
> implementation to figure out what the right interface is. So yes, I'll do
> that before the merge.
>
>> Also, there are oher methods in the interpreter that we
>> might want to propagate up to the frontend, like push and pull.
>> Thoughts?
>
> Not sure this is urgent. I haven't used them so far. But maybe. I want to
> have a "pyshell" interface for my frontend, maybe in a subclass. This is
> important as the frontend should be a drop-in replacmeent for pyshell.
>
>> 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.
>
> Absolutely. This is an experiment, and I was waiting for Fernando to be
> done with his testing to be able to work on that. prefilterfrontend.py
> should be called "dirtyhackfrontend.py" IMHO.
>
>> But, we might run into a problem with doing this stuff (that cool hack
>> that is begin used currently) in the Interpreter.  The reason is that
>> the Interpreter is block based, whereas the prefilter stuff in IPython
>> is only line based.  Thus, doing this refactoring might be a little
>> more involved.  But it is the eventual design we want to go for.  This
>> stuff probably won't be done before the merge. We can work on this at
>> SciPy.
>
> Once again, thanks a lot for your detailed feedback, it is very valuable
> to me.
>
> Gaël
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>