[IPython-dev] strange namespace issue

Fernando Perez fperez.net at gmail.com
Fri Sep 14 02:50:23 EDT 2007


On 9/11/07, Darren Dale <dd55 at cornell.edu> wrote:

> These are the specific changes that are causing some trouble. I dont quite
> follow what is being done here. Is a module being injected into the
> namespace, or is the entire namespace being overwritten? This post I pointed
> out earlier (http://osdir.com/ml/web.zope.devel/2004-02/msg00051.html) might
> still be relevant. Maybe the new code is overwriting an important namespace
> reference, and should instead be updating it?

OK, between your info and Jorgen's I understood the problem.  IPython
does a fair amount of rather complicated gymnastics to emulate a naked
execfile() environment while offering the user the illusion of having
his 'own' execution namespace.  This isn't trivial, because IPython
*itself* is a mass of python objects living inside of the same
interpreter, and it must create this world-within-a-world in as
realistic a way as possible.

As it turns out, my changes were having problems because now this is
done using a real module object (which is good, since it lets for
example doctest work).  But when the Python interpreter tears down a
module object, it resets *in place* all its members to None,
regardless of who may be holding a reference to it.  That's where all
those weird None errors were coming from, as I fell in a trap already
described by a much better pen than me:

    I stand amid the roar
    Of a surf-tormented shore,
    And I hold within my hand
    Grains of the golden sand-
    How few! yet how they creep
    Through my fingers to the deep,
    While I weep- while I weep!
    O God! can I not grasp
    Them with a tighter clasp?
    O God! can I not save
    One from the pitiless wave?
    Is all that we see or seem
    But a dream within a dream?

:)

I just committed a solution that's not the most elegant (holding a
private reference to these things), but that I think should work
correctly, and doesn't create any more of a major memory penalty than
we already have anyway.

These changes are a bit delicate and they touch the very core of user
code execution, so more testing from all the willing is *really
needed*.

So please, go forth and reproduce bugs...

Cheers,

f



More information about the IPython-dev mailing list