Python 2.7 possible bug, imported modules "disappears"

Question

I've found something very strange. See this short code below.

import os

class Logger(object):
    def __init__(self):
        self.pid = os.getpid()
        print "os: %s." %os

    def __del__(self):
        print "os: %s." %os

def temp_test_path():
    return "./[%d].log" %(os.getpid())

logger = Logger()

This is intended for illustrative purposes. It just prints the imported module os, on the construstion and destruction of a class (never mind the name Logger). However, when I run this, the module os seems to "disappear" to None in the class destructor. The following is the output.

os: <module 'os' from 'C:\Python27\lib\os.pyc'>.
os: None.

Where is said os: None. is my problem. It should be identical to the first output line. However, look back at the python code above, at the function temp_test_path(). If I alter the name of this function slightly, to say temp_test_pat(), and keep all of the rest of the code exactly the same, and run it, I get the expected output (below).

os: <module 'os' from 'C:\Python27\lib\os.pyc'>.
os: <module 'os' from 'C:\Python27\lib\os.pyc'>.

I can't find any explanation for this except that it's a bug. Can you? By the way I'm using Windows 7 64 bit.

Answer 1

If you are relying on the interpreter shutdown to call your __del__ it could very well be that the os module has already been deleted before your __del__ gets called. Try explicitly doing a del logger in your code and sleep for a bit. This should show it clearly that the code functions as you expect.

I also want to link you to this note in the official documentation that __del__ is not guaranteed to be called in the CPython implementation.

Answer 2

I've reproduced this. Interesting behavior for sure. One thing that you need to realize is that __del__ isn't guaranteed to even be called when the interpreter exits -- Also there is no specified order for finalizing objects at interpreter exit.

Since you're exiting the interpreter, there is no guarantee that os hasn't been deleted first. In this case, it seems that os is in fact being finalized before your Logger object. These things probably happen depending on the order in the globals dictionary.

If we just print the keys of the globals dictionary right before we exit:

for k in globals().keys():
    print k

you'll see:

temp_test_path
__builtins__
__file__
__package__
__name__
Logger
os
__doc__
logger

or:

logger
__builtins__
__file__
__package__
temp_test_pat
__name__
Logger
os
__doc__

Notice where your logger sits, particularly compared to where os sits in the list. With temp_test_pat, logger actually gets finalized First, so os is still bound to something meaningful. However, it gets finalize Last in the case where you use temp_test_path.

If you plan on having an object live until the interpreter is exiting, and you have some cleanup code that you want to run, you could always register a function to be run using atexit.register.