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

[Almar Klein]

<snip>

This certainly sounds like a viable idea, it's basically having a
> simple convention for how third-party codes can detect whether the
> main gui loop is already controlled.
>
> I should note that *right now* Brian is re-working our gui support,
> because for the new 2-process work we can't hook into pyosinputhook
> anymore (since the kernel isn't running in a terminal that reads user
> input anymore, but instead listening on a network port).  I'm working
> on a different part of the code right now so he may pitch in later,
> but this is just to say that the details of how we do things in the
> new zmq-based 2 process code may differ somewhat.
>

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


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.


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".

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.

Cheers,
  Almar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100824/bbf9d917/attachment.html>