[IPython-dev] Status of py3k ipython

[Fernando Perez]

Hi Thomas,

On Sun, Oct 3, 2010 at 1:26 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> After sending that, I did get PyQT installed, when I realised I could get
> the source of the necessary version using apt-get. After some fiddling with
> pyzmq and Cython, I got zmq bindings installed as well, and the
> IPython.frontend test suite passes on my machine, but ipython-qtconsole
> doesn't really work (I guess the twisted dependency needs to be removed from
> the kernel).

Very interesting...  In fact, the twisted dependency shouldn't matter
*at all* for the ipython-qtconsole code, that code uses strictly zmq
and has no twisted dependency:

In [2]: 'twisted' in sys.modules
Out[2]: False

It would be very cool to get the qt console running on py3 (even if
it's only for adventurous users willing to build pyqt themselves).  So
if you show us what the problems are, we may be able to help.  And
getting any fixes you may have made back into pyzmq would be great.
All of the pyzmq/ipython-zmq code is brand new, so the earlier we
catch any py3-noncompliance, the better off we'll be.

>> These two little devils are very peculiar and unpleasant.  They are
>> tests that I managed to write to catch certain obscure edge cases, but
>> they could probably be better written.
>
> In fact, I think they're picking up meaningful errors in the code, just not
> the errors they were intended to find. I'd got into a mess with
> __builtins__, builtins, and __builtin__, which was causing the first problem
> (in fact, the %run command tested restored __builtins__ correctly, but they
> were wrong before it started).
>
> In the second case, ipython seems to lose references to built-in functions
> as it exits before it calls the __del__ method of the object. Could you
> describe what happens in what order as ipython exits?

When ipython exits the only code that is meant to run is whatever we
registered via atexti().  Just grep for atexit and you'll find those.

But the real problem is not what happens to ipython, but to the
*python* interpreter.  When *that* is truly being shut down (i.e.
after atexit calls happen, which occur while the interpreter is still
intact and fully operational), then various objects (including modules
and possibly builtins) start getting torn down and may be in
inconsistent state.  So __del__ calls that attempt to make use of
other machinery may well find themselves trying to call things that
have become None, and thus blow up.

I hope this helps

f