<br><br><div class="gmail_quote">On Sun, Oct 3, 2010 at 16:33, Thomas Kluyver <span dir="ltr">&lt;<a href="mailto:takowl@gmail.com">takowl@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div class="im">On 3 October 2010 21:43, Fernando Perez <span dir="ltr">&lt;<a href="http://fperez.net" target="_blank">fperez.net</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>&gt;</span> wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">

Hi Thomas,<br>
<div><br>
</div><div class="im">Very interesting...  In fact, the twisted dependency shouldn&#39;t matter<br>
*at all* for the ipython-qtconsole code, that code uses strictly zmq<br>
and has no twisted dependency:<br></div></blockquote><div><br>Hmm, interesting. I&#39;d tried to import IPython.kernel in a shell session, and it fell over trying to import twisted, so I assumed that the frontend code needed the kernel code.<br>



<br>What it does: The Qt app starts up, and I get the banner message printed (Python version, copyright etc., IPython version, pointers to help systems). There&#39;s enough blank space that I can just scroll down to show a blank view. However, there&#39;s no prompt of any sort, and typing doesn&#39;t seem to do anything. At the terminal where I started it, I see some KSharedDataCache messages (related to icons--I&#39;m running KDE), &quot;Starting the kernel at...&quot;, details of four channels, and &quot;To connect another client...&quot;.  There were previously some error messages at the terminal too, but I tracked them down and fixed them easily enough.<br>



<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
And getting any fixes you may have made back into pyzmq would be great.<br>
All of the pyzmq/ipython-zmq code is brand new, so the earlier we<br>
catch any py3-noncompliance, the better off we&#39;ll be.<br></blockquote></div><div><br>You can see my changes at <a href="http://github.com/takowl/pyzmq/tree/py3zmq" target="_blank">http://github.com/takowl/pyzmq/tree/py3zmq</a> (look particularly at this commit, after I&#39;d realised that I should change the .pyx files, not the .c files: <a href="http://github.com/takowl/pyzmq/commit/8261e19189c6733f312e248bf77ee485286634d8" target="_blank">http://github.com/takowl/pyzmq/commit/8261e19189c6733f312e248bf77ee485286634d8</a> ).<br>



<br>In particular, there are a couple of places where you test for Python 3 to decide how to do something. When this is converted to C and compiled, the compiler can&#39;t find the relevant symbols for the Python 2 alternative. I don&#39;t know if Cython allows you to do the equivalent of C preprocessor code, so to get it working, I just commented out the Python 2 sections.<br>

</div></div></blockquote><div><br></div><div>Thanks for figuring this out, but there are a couple issues.  We actually need the buffer code to work on *both* Python 2 and 3, so commenting things out doesn&#39;t work.  It does help find the real issues elsewhere, though.  That file, as it started in mpi4py, works on Pythons 2.3-3.2, but I have clearly broken some of them when I made my adjustments bringing it into pyzmq.  I will work these issues out.</div>

<div><br></div><div>As for the PyUnicode instead of PyString: We actually want to enforce PyBytes in Python 3, not PyUnicode.  It&#39;s critically important that pyzmq never has to deal with Python Unicode objects except through _unicode convenience methods, due to heinous memory performance issues I won&#39;t get into here (but have gotten into plenty with Brian and Fernando).</div>

<div><br></div><div>Thanks,</div><div>-MinRK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>

<br>For the change to Cython that&#39;s needed at present, see the attached patch.<br>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
When ipython exits the only code that is meant to run is whatever we<br>
registered via atexti().  Just grep for atexit and you&#39;ll find those.<br>
<br>
But the real problem is not what happens to ipython, but to the<br>
*python* interpreter.  When *that* is truly being shut down (i.e.<br>
after atexit calls happen, which occur while the interpreter is still<br>
intact and fully operational), then various objects (including modules<br>
and possibly builtins) start getting torn down and may be in<br>
inconsistent state.  So __del__ calls that attempt to make use of<br>
other machinery may well find themselves trying to call things that<br>
have become None, and thus blow up.<font color="#888888"><br></font></blockquote></div><div><br>Well, atexit triggers .reset() of the InteractiveShell object, which looks like it should delete locally created variables. And it does; I&#39;ve just tried that a=A() example, and calling ip.reset() gives me the same &quot;ignored&quot; NameError as exiting the shell. Which is odd, because if I manually do the first step in .reset, clear()-ing each dictionary in .ns_refs_table, the &quot;object A deleted&quot; message pops out flawlessly. Thanks for the information, although I still can&#39;t work out exactly where the problem is.<br>



<br>For what it&#39;s worth, I did try running the same snippet of code in plain python 3.1, and it works as it should.<br><br>Thanks,<br>Thomas<br></div></div>
<br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br>