Hi Fernando,<br><br><div class="gmail_quote">On 25 August 2010 00:08, Fernando Perez <span dir="ltr"><<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">gmail.com</a>></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 class="im"><br>
On Tue, Aug 24, 2010 at 1:38 PM, Almar Klein <<a href="mailto:almar.klein@gmail.com">almar.klein@gmail.com</a>> wrote:<br>
> Interesting. IEP runs its interpreter in a different processes also. You (or<br>
> Brian) might be interested in the channels module which IEP uses for<br>
> communication (via a socket, full Unicode support). You'd be happy to know I<br>
> choose to license it separately as BSD, since I thought it might be useful<br>
> for other projects.<br>
> <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're pretty sure we'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'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's an entire<br>
messaging architecture that we do benefit from at multiple points<br>
(witness Min'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><br>This zmq looks interesting indeed. I should take a look at it in the future. <br><br>A common API, that'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'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><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 'DSB' license<br></blockquote><div><br>Woops, thanks for noticing.<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;">
- 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 class="im"></div></blockquote><div><br>You're right. I will change the names today.<br><br> <snip><br>
</div><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 class="h5">
>> On a different topic: I downloaded iep's hg tip to have a look, but I<br>
>> realized that your code is GPL, so I preferred not to go much deeper<br>
>> into it. I would like to at least ask that you consider releasing<br>
>> your code with a license that makes it easier to share code between<br>
>> iep and ipython, numpy, matplotlib, etc. You mention how code and<br>
>> ideas in ipython have benefitted you in various places, and I think<br>
>> that's great. However, by building a GPL code, you are in fact<br>
>> creating an asymmetric relationship: you can use our code and ideas,<br>
>> but we can't use yours. IPython, numpy, matplotlib, scipy, mayavi,<br>
>> chaco and all the other scientific python tools you benefit from daily<br>
>> are all released under the BSD license (like Python itself), which<br>
>> makes it very easy to share code across all of them. But a single<br>
>> (small or large) application that is GPL in this ecosystem becomes a<br>
>> one-way street: that project can use all the others, but it doesn't<br>
>> give anything back.<br>
>><br>
>> I obviously respect your decision to release your code as GPL, it is<br>
>> your legal right to do so. I would only ask that you consider how the<br>
>> hundreds of thousands of lines of code combined in ipython, mpl,<br>
>> numpy, scipy, etc (and the time this community has contributed to<br>
>> create and maintain them) have benefitted you when working and<br>
>> creating IEP, and how you'd like to participate in this community as a<br>
>> fellow contributor. We've built a great community of projects that<br>
>> all share back and forth with each other, it would be great if IEP was<br>
>> a new member of this same community instead of only taking from it.<br>
><br>
> You bring forward compelling arguments. I will seriously reconsider the<br>
> license.<br>
><br>
> I find this license landscape quite difficult to comprehend sometimes. I<br>
> mean, GPL has it going for it that it protects the code from being used<br>
> commercially, which is good right? At least if I should believe Richard<br>
> Stallman :) In a landscape dominated by GPL code this would make sense,<br>
> since projects would be able to borrow from each other. However, you're<br>
> right: in the Python landscape BSD is the norm, which means a GPL project<br>
> would not "fit in".<br>
<br>
</div></div>Many thanks for giving it some thought. It is indeed a matter of<br>
'ecosystems': in the python one, BSD is a very natural fit and GPL<br>
projects actually create islands with one-way flow of code. I'll be<br>
happy to discuss it further if you have any other questions or ideas.<br>
</blockquote><div><br>Well, I have one question: can I use the BSD license even though IEP uses PyQt (which is GPL)?<br></div><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 class="im">
> Please note that it's not my intention to only "take", or I would not have<br>
> released IEP in the first place. The only problem is that other projects<br>
> cannot easily borrow code from IEP if they're not GPL itself. I'll need to<br>
> give this some thought.<br>
<br>
</div>Certainly, and I apologize if the tone of that last comment of mine<br>
wasn'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 'taking' of<br>
*code* being only one way. I didn't mean to imply a selfish or<br>
unethical attitude on your part, and sorry if my wording wasn't the<br>
best.<br></blockquote><div><br>Well, your words had a sharp edge to it, but I understood what you meant. No hard feelings :)<br><br> Almar<br><br></div></div>