error at "import anydbm"

[Skip Montanaro]

    Paul> What if the standard library modules were put into a "std"
    Paul> package, to help get them out of the global import namespace?  (Of
    Paul> course, this would break *scads* of code, so maybe should be
    Paul> deferred to 3.0.  Or for migration purposes, implement this in a
    Paul> 2.x release, and provide shadow xxx imports that import the
    Paul> std.xxx modules.)

This has come up before.  It is definitely PEP territory.  I think it would
be a good idea, though in the short term (e.g., 2.4, 2.5) the best you can
probably hope for is that a std package and the current modules live
side-by-side.

A couple problems were raised during the last go-round on python-dev.  Any
PEP would have to address them:

    1. In a naive implementation these two statements:

        import std.sys
        import sys

       will result in two separate entries in sys.modules and thus the
       module level code will be executed twice.  During a transition period
       you have to assume that an application will have a combination of
       both styles of imports.

    2. A simple way to achieve a std package parallel to the current global
       namespace on Unix-y systems would be to use symbolic links.  This
       won't work on Windows.  You'd like to avoid duplicating modules, in
       part because it would probably make it harder to solve #1 above.

Skip