Mysterious non-module A.sys

[Fredrik Lundh]

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>