[IPython-dev] frontend plans

[Fernando Perez]

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.

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


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


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?

Cheers,

f