[IPython-dev] Uniform way of integrating event loops among different IDE's

[Fernando Perez]

Hi Almar,

On Tue, Aug 24, 2010 at 1:38 PM, Almar Klein <almar.klein at gmail.com> wrote:
> Interesting. IEP runs its interpreter in a different processes also. You (or
> Brian) might be interested in the channels module which IEP uses for
> communication (via a socket, full Unicode support). You'd be happy to know I
> choose to license it separately as BSD, since I thought it might be useful
> for other projects.
> http://code.google.com/p/iep/wiki/Channels

Cool!  We might find ways of making our APIs more compatible with
that, though for the implementation we're pretty sure we're going to
stick with zeromq, at least for a while: zeromq manages the messaging
100% in C++ without any python dependencies, which means that the
messaging layer can continue to manage data even when engines are busy
running C extension code.  For us, that's an important feature.
Zeromq is being developed by a really strong team with years of
experience in high-performance networking, and it's an entire
messaging architecture that we do benefit from at multiple points
(witness Min's recent work).

But it seems like channels offers some of the same basic ideas in pure
python, so it would be cool if we could find a common API so that we
could have a non-zmq multiprocess version (even if it had a few
limitations), using channels.py, and the full zmq-based one for the
rest.

So many thanks for pointing this out, it could be really nice to have
a pure-python fallback mode, so that even the multi-process setups
could be run just on top of the stdlib, even if losing a little bit of
speed and robustness compared to zmq.  Interesting...

A few minor notes:

- typo in the site, it reads 'DSB' license

- Since this is new code, may I suggest you use PEP-8 naming
conventions?  While in places like code that inherits from Wx or Qt
one has no option but following its own naming scheme, these days most
python code has standardized on PEP-8 naming style (ClassNames and
functions_or_methods).  It would be good to see new code (especially
code landing for py3) arriving in a consistent style with this.

>> But regardless of what changes we end up having in console vs.
>> network, I do think that standardizing a 'protocol' for applications
>> that can expose an interactive event loop to sync with user's gui code
>> is definitely what we want to have.   Once a clean solution is in
>> place, matplotlib, chaco and friends can be adjusted to a common
>> standard and work with ipython, iep, etc. in a single shot.
>
> Great to hear you're interested. As soon as things fall into place for
> IPython, we should get in contact and discuss how we want to do that.

Yup!

>> On a different topic: I downloaded iep's hg tip to have a look, but I
>> realized that your code is GPL, so I preferred not to go much deeper
>> into it.  I would like to at least ask that you consider releasing
>> your code with a license that makes it easier to share code between
>> iep and ipython, numpy, matplotlib, etc.  You mention how code and
>> ideas in ipython have benefitted you in various places, and I think
>> that's great.  However, by building a GPL code, you are in fact
>> creating an asymmetric relationship: you can use our code and ideas,
>> but we can't use yours.  IPython, numpy, matplotlib, scipy, mayavi,
>> chaco and all the other scientific python tools you benefit from daily
>> are all released under the BSD license (like Python itself), which
>> makes it very easy to share code across all of them.  But a single
>> (small or large) application that is GPL in this ecosystem becomes a
>> one-way street: that project can use all the others, but it doesn't
>> give anything back.
>>
>> I obviously respect your decision to release your code as GPL, it is
>> your legal right to do so.  I would only ask that you consider how the
>> hundreds of thousands of lines of code combined in ipython, mpl,
>> numpy, scipy, etc (and the time this community has contributed to
>> create and maintain them) have benefitted you when working and
>> creating IEP, and how you'd like to participate in this community as a
>> fellow contributor.  We've built a great community of projects that
>> all share back and forth with each other, it would be great if IEP was
>> a new member of this same community instead of only taking from it.
>
> You bring forward compelling arguments. I will seriously reconsider the
> license.
>
> I find this license landscape quite difficult to comprehend sometimes. I
> mean, GPL has it going for it that it protects the code from being used
> commercially, which is good right? At least if I should believe Richard
> Stallman :)  In a landscape dominated by GPL code this would make sense,
> since projects would be able to borrow from each other. However, you're
> right: in the Python landscape BSD is the norm, which means a GPL project
> would not "fit in".

Many thanks for giving it some thought.  It is indeed a matter of
'ecosystems': in the python one, BSD is a very natural fit and GPL
projects actually create islands with one-way flow of code.  I'll be
happy to discuss it further if you have any other questions or ideas.

> Please note that it's not my intention to only "take", or I would not have
> released IEP in the first place. The only problem is that other projects
> cannot easily borrow code from IEP if they're not GPL itself. I'll need to
> give this some thought.

Certainly, and I apologize if the tone of that last comment of mine
wasn't quite right, I only realized it after re-reading it.  I
certainly appreciate your contribution, and would quite possibly use
IEP (as a *user*) regardless of the GPL/BSD issue.  Users can and will
benefit from your contribution, and for that alone you are already to
be thanked.  My comment had a narrow scope: regarding the 'taking' of
*code* being only one way.  I didn't mean to imply a selfish or
unethical attitude on your part, and sorry if my wording wasn't the
best.

Regards,

f