[IPython-dev] [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
Sat Sep 4 01:57:13 CDT 2010
On Fri, Sep 3, 2010 at 11:16 PM, Michiel de Hoon <firstname.lastname@example.org> wrote:
> Then I prefer to wait until ZMQ is fixed.
Note that it's not a matter of 'fixing': part of the design of zmq, as
best as I understand it, precisely requires that the low-level fds be
kept completely *private* to zmq and *never* exposed to the library
users. This allows zmq to expose networking semantics that are
richer, more flexible and easier to use than classic socket ones. But
the price you pay is that manual manipulation of certain internal
details becomes forbidden.
Cases like this are very common in software: you hide something to
expose a different high-level interface, and users can *not* decide to
manipulate the private bits of your object and come out unscathed.
It's like having a C extension that sets a pointer to a numpy array's
buffer and assumes it can work with it forever, forgetting reference
counting: at some point python may delete that high-level object, and
the code that "went behind numpy's back" will break.
So zmq is not 'broken', it's *different* from a purely fd-based
network api. And as Brian indicated, even if they do offer something
that looks like a fd, it may not be quite the one that other event
loops expect, so integration by 'melding' event loops may never be
Keep in mind that these design choices in zmq make it a *phenomenal*
library in many ways, whose semantics are clear and easy to work with,
so this is a price that we are happy to pay.
And the point about orthogonality Brian made is also important to keep
in mind: by blending event loops, we'd need N implementations of
gui+zmq for N GUI toolkits. That's a maintenance *nightmare*,
considering how currently our networking logic can stay completely
uncoupled from GUI specifics.
In summary, the approach we've used with Qt/Wx of simply calling the
zmq loop on an idle timer of the GUI event loop works fine, keeps the
coupling between networking and GUI code to a *tiny* mininum, and has
only a very small performance penalty.
In software development, optmizing for a little performance at an
astronomical complexity and maintainability cost isn't a good idea.
The new architecture we have is very nice but not exactly trivial;
weaving 4 gui toolkits into its very core would likely gum it up with
impossible to debug problems.
I hope you see why we're looking for a more decoupled approach. It's
not a hack, it's a solution based on a set of well defined reasons
based on the problem at hand.
Thanks for your feedback.
More information about the IPython-dev