Hi IPython developers,<br><br>Let me explain about our choice to implement Yoton instead of using pyzmq.<br><br><br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the pointer, I saw the announcement of IEP, but not the<br>
yoton one.  It looks extremely similar to zmq (down to the project<br>
motto &quot;Easiest. Messaging. Ever&quot;, for zeromq a while back I think it<br>
read &quot;Fastest. Messaging. Ever&quot;).  </blockquote><div><br>I definitely had ZMQ inspire me for the design. The motto is indeed shamelessly stolen from zmq&#39;s motton; it should not be taken too seriously, but more as a wink to the zmq project ;)<br>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But I don&#39;t quite see the point of<br>
reimplementing pyzmq: zeromq is already very good, has fantastic<br>
python bindings, and there&#39;s a very good reason to want your low-level<br>
networking machinery to be implemented in C++ instead of Python: the<br>
GIL.<br></blockquote><div><br>The main reason for developing a pure python communication layer was because I wanted IEP to work with any Python version installed on a system (Python v2.4 and up), without having to install any extra packages. The idea is that you can just install the binary version of IEP and get started. <br>
<br>I already had working code for this (you recalled our discussion from september 2010) when I learned about zmq and pyzmq. I have seen the documentation of IPython for the communication between the kernel and client, and although it all made a lot of sense, I foresaw some incompatibilities with our ideas about the relation between the kernel and the client. I cannot recall the details, but I believe the main difference is that IPython considers the kernel to be &quot;in charge&quot;, while IEP considers the kernel to be a &quot;slave&quot;.<br>
<br>Considering that I already had working code, I decided to refactor it to make the code more clear, and introducing functionality to connect multiple context in a network: I really like IPython&#39;s idea about remote and collaborative computing. As always, I underestimated the work that was needed to get it right. In this case I underestimated it *a lot*. But anyway, this resulted in Yoton.<br>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Most of ipython&#39;s communications code continues to function regardless<br>
of the load on the python process and whatever may be happening to the<br>
GIL, and that&#39;s a pretty darn important point (there are obviously<br>
parts that need the gil, but a good amount happens independent of it).<br>
 Believe, we know: we used Twisted for years, and we saw the impact<br>
this could have for use cases like engines meant to do heavy-duty<br>
computing.<br></blockquote><div><br>Indeed, if the kernel is running extension code, the kernel and IDE cannot communicate. But we can still distinguish between the kernel being dead and the kernel running extension code. If we connect via localhost, the socket-pair always remains intact unless the process dies (or the socket is closed explicitly of course). So if we do not receive heart beat signals, but we do not detect a socket problem, we know that the process is running extension code (this is also visualised in the shell-icon in IEP). This does mean we need a connection via localhost, so we always use a broker that runs on the same machine as the kernel. This has other advantages; we also read the kernel&#39;s stdout and stderr via a pipe and send these messages to the IDE via Yoton. <br>
<br>Certainly, zmq has a better performance, but Yoton easily matches the requirements needed for kernel-ide communication.<br><br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

But hey, as long as they have fun working on it, that&#39;s all that<br>
matters.  I&#39;m not being sarcastic here, I mean this: people should<br>
feel free to play even with projects that seem redundant/pointless to<br>
others, and I&#39;m not criticizing them at all.  *I* don&#39;t see the point<br>
for myself, but that doesn&#39;t matter.  And who knows, the ease of<br>
development of Python may take them in interesting new directions that<br>
zmq isn&#39;t exploring, so in the long run it may prove to be a very<br>
useful project.<br></blockquote><div><br>Thanks for your understanding :)  Yes we did have a lot of fun. And a lot of pain and frustration, but we learned a lot in the end.<br><br>One more thing that might be of interest. Yoton has a feature for the pub-sub pattern to slow down the sending side if the receiver cannot keep up processing messages. Therefore we can guarantee that the user will not miss any messages. Try running &quot;while True: print(time.time())&quot;.<br>
<br>Regards,<br>  Almar<br></div></div><br>-- <br>Almar Klein, PhD<br>Science Applied<br>phone: +31 6 19268652<br>e-mail: <a href="mailto:a.klein@science-applied.nl" target="_blank">a.klein@science-applied.nl</a><br><br>