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."
--
http://mail.python.org/mailman/listinfo/python-list