== An interesting Python garbage collection bug

Derived from [[here
http://www.voidspace.org.uk/python/weblog/arch_d7_2006_11_04.shtml#e535]]:

>  import sys
>  x = 10
>  del sys.modules['__main__']
>  print x

If you execute this at the interpreter prompt, you get a NameError
that _x_ is not defined. If you execute it as a file (or if you put
the sys.modules and print bit in a function and run the function),
you get _None_ printed.

The interpreter situation makes a certain amount of sense, once you
discover that the interpreter is holding no references to anything
from prompt to prompt. The _del_ drops the reference count on the real
__main__ to zero, causing it to be garbage collected, and you are left
with no namespace at all.

(Technically what happens is that the interpreter recreates a new
__main__ at the next line, but it is empty. You can't do much with
this, since you can't successfully import __builtins__ to start
reconstructing an environment.)

The function case makes sense once you think about cyclic garbage
collection. While the executing function has a reference to __main__,
__main__ also holds a reference to it, making it a cyclic reference and
thus not enough to keep __main__ alive.
The peculiar result is because of how CPython cleans up modules that are
getting garbage collected; in order to help out destructors, it follows
a complicated dance of setting module-level names to _None_ (in two
passes, and excluding __builtins__, so that destructors can still get at
builtin objects), instead of actually deleting them outright.

I call this a bug because I believe that executing code should be
considered to be holding an external reference to its module, and that
the interpreter should similarly hold an external reference to __main__
in general. Python may be doing what you told it to here, but it's
not anywhere near what I think most people would expect.