[IPython-dev] strange namespace issue
Fri Sep 14 01:50:23 CDT 2007
On 9/11/07, Darren Dale <firstname.lastname@example.org> 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
So please, go forth and reproduce bugs...
More information about the IPython-dev