Robin Becker wrote: >I have a package A containing a null __init__.py and a simple module B.py > > C:\code>cat A\B.py > import sys > print __file__ > print sys.modules.keys() > > C:\code>python -c"import A.B" > A\B.py > ['copy_reg', 'A.B', 'locale', '__main__', 'site', '__builtin__', 'encodings', > 'os.path', 'A.sys', 'encodings.codecs', 'ntpath', 'UserDict', > 'encodings.exceptions', 'nt', 'A', 'stat', 'zipimport', 'warnings', > 'encodings.types', '_codecs', 'encodings.cp1252', 'sys', 'codecs', 'types', > '_locale', 'signal', 'linecache', 'encodings.aliases', 'exceptions', 'os'] > > C:\code> > > where does A.sys come from?
http://www.python.org/doc/essays/packages.html "Dummy Entries in sys.modules "When using packages, you may occasionally find spurious entries in sys.modules, e.g. sys.modules['Sound.Effects.string'] could be found with the value None. This is an "indirection" entry created because some submodule in the Sound.Effects package imported the top-level string module. Its purpose is an important optimization: because the import statement cannot tell whether a local or global module is wanted, and because the rules state that a local module (in the same package) hides a global module with the same name, the import statement must search the package's search path before looking for a (possibly already imported) global module. Since searching the package's path is a relatively expensive operation, and importing an already imported module is supposed to be cheap (in the order of one or two dictionary lookups) an optimization is in order. The dummy entry avoids searching the package's path when the same global module is imported from the second time by a submodule of the same package." </F> -- http://mail.python.org/mailman/listinfo/python-list
