<br><br><div class="gmail_quote">On 25 August 2010 10:10, Almar Klein <span dir="ltr">&lt;<a href="mailto:almar.klein@gmail.com">almar.klein@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Fernando,<br><br><div class="gmail_quote"><div><div></div><div class="h5">On 25 August 2010 00:08, Fernando Perez <span dir="ltr">&lt;<a href="http://fperez.net" target="_blank">fperez.net</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Almar,<br>
<div><br>
On Tue, Aug 24, 2010 at 1:38 PM, Almar Klein &lt;<a href="mailto:almar.klein@gmail.com" target="_blank">almar.klein@gmail.com</a>&gt; wrote:<br>
&gt; Interesting. IEP runs its interpreter in a different processes also. You (or<br>
&gt; Brian) might be interested in the channels module which IEP uses for<br>
&gt; communication (via a socket, full Unicode support). You&#39;d be happy to know I<br>
&gt; choose to license it separately as BSD, since I thought it might be useful<br>
&gt; for other projects.<br>
&gt; <a href="http://code.google.com/p/iep/wiki/Channels" target="_blank">http://code.google.com/p/iep/wiki/Channels</a><br>
<br>
</div>Cool!  We might find ways of making our APIs more compatible with<br>
that, though for the implementation we&#39;re pretty sure we&#39;re going to<br>
stick with zeromq, at least for a while: zeromq manages the messaging<br>
100% in C++ without any python dependencies, which means that the<br>
messaging layer can continue to manage data even when engines are busy<br>
running C extension code.  For us, that&#39;s an important feature.<br>
Zeromq is being developed by a really strong team with years of<br>
experience in high-performance networking, and it&#39;s an entire<br>
messaging architecture that we do benefit from at multiple points<br>
(witness Min&#39;s recent work).<br>
<br>
But it seems like channels offers some of the same basic ideas in pure<br>
python, so it would be cool if we could find a common API so that we<br>
could have a non-zmq multiprocess version (even if it had a few<br>
limitations), using channels.py, and the full zmq-based one for the<br>
rest.<br>
<br>
So many thanks for pointing this out, it could be really nice to have<br>
a pure-python fallback mode, so that even the multi-process setups<br>
could be run just on top of the stdlib, even if losing a little bit of<br>
speed and robustness compared to zmq.  Interesting...<br></blockquote></div></div><div><br>This zmq looks interesting indeed. I should take a look at it in the future. <br><br>A common API, that&#39;s an interesting idea. We might even cooperate on creating a package specifically for this kind of inter process communication, that would use zmq if it can and falls back to pure Python otherwise.<br>

<br>Thinking of wilder ideas, it might even be possible to share a common interpreter (with which I mean the code running in the second process). Such that only the way of controlling it is different. Whether one uses IPython or IEP, under the hood it&#39;s the same thing. There are of course some fundamental differences between IEP and IPython (for example IEP needs to be able to run a selection of code), but who knows?<br>

<br><br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- typo in the site, it reads &#39;DSB&#39; license<br></blockquote></div><div><br>Woops, thanks for noticing.<br> <br><br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


- Since this is new code, may I suggest you use PEP-8 naming<br>
conventions?  While in places like code that inherits from Wx or Qt<br>
one has no option but following its own naming scheme, these days most<br>
python code has standardized on PEP-8 naming style (ClassNames and<br>
functions_or_methods).  It would be good to see new code (especially<br>
code landing for py3) arriving in a consistent style with this.<br><div></div></blockquote></div><div><br>You&#39;re right. I will change the names today.<br><br> &lt;snip&gt;<br>
</div><div><div></div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div>
&gt;&gt; On a different topic: I downloaded iep&#39;s hg tip to have a look, but I<br>
&gt;&gt; realized that your code is GPL, so I preferred not to go much deeper<br>
&gt;&gt; into it.  I would like to at least ask that you consider releasing<br>
&gt;&gt; your code with a license that makes it easier to share code between<br>
&gt;&gt; iep and ipython, numpy, matplotlib, etc.  You mention how code and<br>
&gt;&gt; ideas in ipython have benefitted you in various places, and I think<br>
&gt;&gt; that&#39;s great.  However, by building a GPL code, you are in fact<br>
&gt;&gt; creating an asymmetric relationship: you can use our code and ideas,<br>
&gt;&gt; but we can&#39;t use yours.  IPython, numpy, matplotlib, scipy, mayavi,<br>
&gt;&gt; chaco and all the other scientific python tools you benefit from daily<br>
&gt;&gt; are all released under the BSD license (like Python itself), which<br>
&gt;&gt; makes it very easy to share code across all of them.  But a single<br>
&gt;&gt; (small or large) application that is GPL in this ecosystem becomes a<br>
&gt;&gt; one-way street: that project can use all the others, but it doesn&#39;t<br>
&gt;&gt; give anything back.<br>
&gt;&gt;<br>
&gt;&gt; I obviously respect your decision to release your code as GPL, it is<br>
&gt;&gt; your legal right to do so.  I would only ask that you consider how the<br>
&gt;&gt; hundreds of thousands of lines of code combined in ipython, mpl,<br>
&gt;&gt; numpy, scipy, etc (and the time this community has contributed to<br>
&gt;&gt; create and maintain them) have benefitted you when working and<br>
&gt;&gt; creating IEP, and how you&#39;d like to participate in this community as a<br>
&gt;&gt; fellow contributor.  We&#39;ve built a great community of projects that<br>
&gt;&gt; all share back and forth with each other, it would be great if IEP was<br>
&gt;&gt; a new member of this same community instead of only taking from it.<br>
&gt;<br>
&gt; You bring forward compelling arguments. I will seriously reconsider the<br>
&gt; license.<br>
&gt;<br>
&gt; I find this license landscape quite difficult to comprehend sometimes. I<br>
&gt; mean, GPL has it going for it that it protects the code from being used<br>
&gt; commercially, which is good right? At least if I should believe Richard<br>
&gt; Stallman :)  In a landscape dominated by GPL code this would make sense,<br>
&gt; since projects would be able to borrow from each other. However, you&#39;re<br>
&gt; right: in the Python landscape BSD is the norm, which means a GPL project<br>
&gt; would not &quot;fit in&quot;.<br>
<br>
</div></div>Many thanks for giving it some thought.  It is indeed a matter of<br>
&#39;ecosystems&#39;: in the python one, BSD is a very natural fit and GPL<br>
projects actually create islands with one-way flow of code.  I&#39;ll be<br>
happy to discuss it further if you have any other questions or ideas.<br>
</blockquote></div></div><div><br>Well, I have one question: can I use the BSD license even though IEP uses PyQt (which is GPL)?<br></div><div class="im"><div> <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;">

<div>
&gt; Please note that it&#39;s not my intention to only &quot;take&quot;, or I would not have<br>
&gt; released IEP in the first place. The only problem is that other projects<br>
&gt; cannot easily borrow code from IEP if they&#39;re not GPL itself. I&#39;ll need to<br>
&gt; give this some thought.<br>
<br>
</div>Certainly, and I apologize if the tone of that last comment of mine<br>
wasn&#39;t quite right, I only realized it after re-reading it.  I<br>
certainly appreciate your contribution, and would quite possibly use<br>
IEP (as a *user*) regardless of the GPL/BSD issue.  Users can and will<br>
benefit from your contribution, and for that alone you are already to<br>
be thanked.  My comment had a narrow scope: regarding the &#39;taking&#39; of<br>
*code* being only one way.  I didn&#39;t mean to imply a selfish or<br>
unethical attitude on your part, and sorry if my wording wasn&#39;t the<br>
best.<br></blockquote></div><div><br>Well, your words had a sharp edge to it, but I understood what you meant. No hard feelings :)<br><br>  Almar<br></div></div></blockquote><div><br>On whether I&#39;d be allowed to use the BSD license, I found this exception to the GPL license, that is used by both Nokia and Riverbank:<br>
<a href="http://doc.trolltech.com/4.4/license-gpl-exceptions.html">http://doc.trolltech.com/4.4/license-gpl-exceptions.html</a><br><br>As for as I can see, item 2 (at the bottom) covers it already, because IEP links to the precompiled binaries. <br>
<br>  Almar<br></div></div>