Fernando,<br><br><div class="gmail_quote">On Tue, Oct 26, 2010 at 1:48 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
</div>That sound like a good plan to me, modulo that I'd base your current<br>
work on the 0.10.2 branch here:<br>
<br>
<a href="http://github.com/ipython/ipython/tree/0.10.2" target="_blank">http://github.com/ipython/ipython/tree/0.10.2</a><br>
<br>
that has the most recent code that's still 2.5-compatible.<br>
<br></blockquote><div>Sounds good, I will do that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Sorry about the fact that we'd moved to 2.6 just as you guys showed up<br>
:)</blockquote><div><br></div><div>No problem at all. It would've been nice that readline had been better defined with a test suite, or we might have had done this last year. So anything that ipython trunk can do to test via pexpect (or something like that) will be very helpful. (Jython can transparently drive pexpect with execnet, through a subprocess gateway).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">  The real motivation for that was getting things ready for the 3.x<br>
transition, and we figured that 2.6 being out for over 2 years was<br>
enough of a window that we took the jump.  Hopefully before long your<br>
2.6/7 work will be stable enough that this won't be a problem anymore.<br></blockquote><div><br></div><div>We're probably 6 months away from a usable early release (alpha), so it's reasonable. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<br>
One interesting possibility opened by the new ZeroMQ-based model will<br>
be the ability to use any client (such as the nice Qt one or the new<br>
web one) to talk to a Jython-based kernel.  You could thus benefit<br>
from the client work done by others while talking to a kernel running<br>
on the JVM and accessing your Java libs.<br></blockquote><div><br></div><div>This is a real use case that frequently comes up.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
And conversely, you could write a pure Java client (in say Eclipse or<br>
any other Java tool) that could talk to a CPython kernel, so that for<br>
example people who like the Java tool could operate on<br>
numpy/scipy/matplotlib backends from their familiar environments.<br>
<br></blockquote><div>I'm also looking forward to when users can also mix in a single process Java libraries <b>and</b> C/C++/Fortran-based libraries, including numpy/*,  once we support the Python C Extension API. It also looks feasible to support memoryview via Java NIO buffers, so this could be done without impacting the JIT and with zerocopy.</div>

<div> </div><div>- Jim</div></div><br>