[IPython-dev] Fwd: [SciPy-User] ANN: IEP 3.0.beta - the Interactive Editor for Python

Fernando Perez fperez.net@gmail....
Fri Apr 20 22:46:18 CDT 2012

Hey Jason,

On Fri, Apr 20, 2012 at 7:52 PM, Jason Grout
<jason-sage@creativetrax.com> wrote:
> Some of you probably saw this message on the scipy list.  I thought that the
> "Yoton" library they are developing sounded intriguing for the IPython
> crowd.  It seems that there are several libraries being developed these days
> to allow python-controlled remote execution kernels (2 such things in
> Sage---sage cell server and william's sage workspace code [1], this yoton
> project, and of course, your client/kernel code). We should at least know
> about each other.
> http://code.google.com/p/yoton/

Thanks for the pointer, I saw the announcement of IEP, but not the
yoton one.  It looks extremely similar to zmq (down to the project
motto "Easiest. Messaging. Ever", for zeromq a while back I think it
read "Fastest. Messaging. Ever").  But I don't quite see the point of
reimplementing pyzmq: zeromq is already very good, has fantastic
python bindings, and there's a very good reason to want your low-level
networking machinery to be implemented in C++ instead of Python: the

Most of ipython's communications code continues to function regardless
of the load on the python process and whatever may be happening to the
GIL, and that's a pretty darn important point (there are obviously
parts that need the gil, but a good amount happens independent of it).
 Believe, we know: we used Twisted for years, and we saw the impact
this could have for use cases like engines meant to do heavy-duty

My take on this is: IPython offers very nice abstractions for certain
workloads *on top* of zeromq, and for many problems is the right tool
to use.  For many others, pyzmq itself may be a better fit, and not
IPython, and that's fine.  But rewriting zeromq itself just so it can
have worse performance and be bound to the constraints of the GIL?  I
don't get it.

And you're right that their design brief is more or less identical to
IPython's design:


This was started in September 2010, time by which we already had
pyzmq, a documented messaging protocol, a public lightweight
prototype, and we were almost finished with the production version of
the full kernel and client libraries as well as the Qt console.  I
kind of wish they'd join forces instead of starting from scratch on a
reimplementation of exactly the same thing we'd just done...
(including rewriting layers below ours, since we didn't have to write
zmq itself!).

But hey, as long as they have fun working on it, that's all that
matters.  I'm not being sarcastic here, I mean this: people should
feel free to play even with projects that seem redundant/pointless to
others, and I'm not criticizing them at all.  *I* don't see the point
for myself, but that doesn't matter.  And who knows, the ease of
development of Python may take them in interesting new directions that
zmq isn't exploring, so in the long run it may prove to be a very
useful project.

But thanks again for the pointer, I'd missed this and it's always good
to know what's out there on similar problems.

I know you keep close tabs on what we're doing (and I try my best to
know what's happening with Sage), so I trust that on the ipython/sage
front, we can make better use of resources by sharing work instead of
duplicating it ;)



More information about the IPython-dev mailing list