Namespace Qualification Question

[Mitch Chapman]

Craig McLean wrote:
> 
> I've been messing around with python namespaces and I've run into
> something that I haven't been able to answer.
> 
> Is there a module assosciated with the file you started the 
> interpreter with, and if there is what is it's name?  For instance
> 
>  > python qux.py
> 
> I would have thought that there would be a qux module, and that it's
> name would be stored in the __name__ builtin.
> 
> If I was using the interpreter interactively would that change things?

When you use a module as your main module its name is "__main__".
This is useful because it lets you use a file as both a module in 
a larger Python application and as a separate command-line utility:
________________________________________________________________________
#!/usr/bin/env python

class Foo:
    ...

def main():
    """Do something useful with all of those command-line arguments."""
    ...

if __name__ == "__main__":
    """Program mainline for standalone execution."""
    main()
________________________________________________________________________

This convention can also lead to subtle bugs, in particular with
module-level state, in particular when your main() logic introduces
a circular import dependency with another module.  

One interesting example of this sort of circular dependency is
unittest.py, the XP-inspired (?) regression test framework which 
is included in the Python standard library.

You use unittest.py by importing it and deriving test cases and 
suites from the base classes it provides:
________________________________________________________________________
# MyTest.py
import unittest

class MyTest(unittest.TestCase):
    ...
________________________________________________________________________

Then to exercise MyTest you do something like this:

$ python unittest.py MyTests.py

In this case unittest is used, in a single Python session,
as both the program mainline and a module providing services
to MyTest.py.

When the above command is run, unittest imports MyTests and 
then searches through it for test cases, suites, etc. derived 
from unittest's own base classes.  Whatever tests it finds, it 
runs.  

But in order to reliably detect subclasses of TestCase, unittest 
must import itself and ask 
	issubclass(obj, unittest.TestCase)
rather than just asking
	issubclass(obj, TestCase)

In the latter fragment "TestCase" refers to "__main__.TestCase".  
But obj comes from MyTests, so if it is a TestCase it will have
been derived from "unittest.TestCase".  As far as Python is 
concerned "__main__.TestCase" is a different beast from
"unittest.TestCase".  

So in order to reliably detect the test cases defined in MyTests,
unittest must import and reference itself under its "published" name.


This also has implications for modules which try to export
singletons or default instances of classes.  Any such module 
Foo which can also be invoked as a main program runs the risk 
of creating two instances of the "singleton", with interesting
results.

-- 
Mitch Chapman
Dang! I'm wordy today