[IPython-dev] frontend plans

[Barry Wark]

On Mon, Jun 30, 2008 at 5:37 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hey folks,
>
> I'm sorry that I failed to respond during this thread, but as it
> happened I was at a conference with only micro-breaks for 'easy'
> emails, but not to digest all of this :)
>
> Having said that, here are a few thoughts on  what has been said so far:
>
> - Gael: as Brian asked, what are your design parameters regarding GUI
> blocking?  If you put the exec calls in a thread (like ipython
> -Xthread does) you have some hope of interface responsiveness, if you
> put them in a process you get full GUI responsiveness at the cost of
> other complexities.  Are you OK with a non-responsive GUI while exec()
> is busy?
>
> - Zope interfaces: what do they exactly bring us?  Nose uses
> interfaces in a non-enforcing way by making them pure python classes
> that are meant to document behavior but *not* to be subclassed.
> Perhaps we could have something similar for the pure python version
> and then a ZI version for the rest of the twisted layer:
>
> class BasicInterface(object):
>  def foo(self,x,y):
>    """does z with x and y"""
>    raise NotImplementedError()
>
> class RealInterface(BasicInterface,zope.interfaces.whatever):
>  pass
>
> Code NOT using twisted would inherit from the first type of functions,
> and all twisted-based code would inherit from the second.

What about something like the following::

try:
    raise ImportError()
    from zope.interface import Interface, Attribute, implements, classProvides
except ImportError:
    def Attribute(name,doc): pass
    def implements(interface): pass
    def classProvides(interface): pass

class IExample(Interface):
    Attribute('name', 'Attribute name __doc__')

    def example_method():
        """example_method"""

        pass


class Implementor(object):
    """Implements  the IExample interface."""

    implements(IExample)

    def example_method(self):
        """example_method"""

        print self

The only thing you don't get is being able to check that Implementor
implements IExample if zope.interface isn't present.

>
> - basic observation: exec() is fundamentally a blocking primitive.  At
> the end of the day, you have to wait for that particular chunk of code
> to finish, and that's the python interpreter itself you're waiting
> for.  For this reason, it makes sense that the lowest level
> abstractions we have should be blocking, and asynchronous interfaces
> are wrapped around those for systems that are 'removed' from this
> execution core (by being out of process, in another computer, etc).
> Yes, I know that exec() could be calling threaded code, but that
> simply means that exec(x) can finish quickly and some of the results
> will be ready later.  But the overall operation of completing the
> execution of 'x' is still a blocking one.
>
> - Because of the above, I'm not crazy about the whole "synchronous
> deferred" use.  In my mind, the logical containment chain is:
>
> (0 - python VM - fundamentally synchronous object) < (1 - Ipython
> layer that manages this) < (2 - Asynchronous wrappers for systems that
> will work out of process, over the network, etc).

I completely agree. The previous discussion convinced me this is the
right way to go.

>
>
> - Tab completion: this is just one case of the more generic case of
> how to represent out-of-process information.  We have to assume that
> in general, only the core has true access to the real in-memory
> objects of the user's namespace.  Clients may request information
> about this for display purposes, and some communication of reduced
> data may happen with such clients, but we can't expect to  copy the
> user's namespace across the wire in a general sense.  So yes, tab
> completion and similar introspection will always happen by clients
> requesting the operation on the core, and the core sending back
> something reasonable back (a list of strings, for example).

Agreed. I think the statement "clients may request information about
this for display purposes" is a somewhat complicated idea that will
require some more work.

>
>
> In summary:  it seems from what Barry said in the end, as well as
> Gael, that we're all happy with the notion of a core, blocking system
> that ultimately is just a bells-and-whistles version of python's "exec
> code in namespace" statement.  It lets you manage that namespace,
> introspect it, it offers extensions, history, etc, but ultimately it's
> just wrapping that one single statement.  Because that statement
> *fundamentally* blocks, this system blocks.  You can embed it in a GUI
> or use it in a terminal, but it still blocks.
>
> Beyond that, it makes sense to wrap this in a Twisted layer that turns
> the result of exec() into a deferred.  This makes complete sense when
> the process doing exec() is different than your own (gui, network,
> etc) and you actively want to move on with your life, while having a
> notification mechanism for handling results/errors arising from the
> exec call.  At this point, the Twisted callback/errback system seems
> well tailored for this.
>
> And I certainly want to ensure that Gael finds the code that's in
> there sufficient for him to use in his WX project.   It seems to me
> that's the case, but have we left any question unanswered on that
> front?

There aren't any immediate questions that I'm aware of.

-Barry

>
> Cheers,
>
> f
>