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

[Almar Klein]

On 25 August 2010 10:10, Almar Klein <almar.klein at gmail.com> wrote:

> Hi Fernando,
>
> On 25 August 2010 00:08, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> 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...
>>
>
> This zmq looks interesting indeed. I should take a look at it in the
> future.
>
> 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.
>
> 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?
>
>
> - typo in the site, it reads 'DSB' license
>>
>
> Woops, thanks for noticing.
>
>
> - 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.
>>
>
> You're right. I will change the names today.
>
>  <snip>
>
>
>> >> 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.
>>
>
> Well, I have one question: can I use the BSD license even though IEP uses
> PyQt (which is GPL)?
>
>
>  > 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.
>>
>
> Well, your words had a sharp edge to it, but I understood what you meant.
> No hard feelings :)
>
>   Almar
>

On whether I'd be allowed to use the BSD license, I found this exception to
the GPL license, that is used by both Nokia and Riverbank:
http://doc.trolltech.com/4.4/license-gpl-exceptions.html

As for as I can see, item 2 (at the bottom) covers it already, because IEP
links to the precompiled binaries.

  Almar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100825/7ac1055c/attachment.html>