error at "import anydbm"

[=?ISO-8859-1?Q?=22C=E9dric_V=2E=22?=]

Hi,

I am unable to import anydbm without error under Python2.2 or 2.3 (Linux).

this script:

>#!/usr/bin/env python
>import anydbm
>
>if __name__ == "__main__":
> db = anydbm.open("test", "rwc")
> db["test"] = "ok"

returns at execution:

>cedric@dev _test $ python dbm.py
>Traceback (most recent call last):
> File "dbm.py", line 2, in ?
> import anydbm
> File "/usr/lib/python2.3/anydbm.py", line 59, in ?
> _errors.append(_mod.error)
>AttributeError: 'module' object has no attribute 'error'

(the same with python2.2)


do I have forgotten something? or is it another problem?

thanks in advance,

-- CV

 

[Peter Hansen]

I am unable to import anydbm without error under Python2.2 or 2.3 (Linux).

this script:

#!/usr/bin/env python
import anydbm

if __name__ == "__main__":
db = anydbm.open("test", "rwc")
db["test"] = "ok"

returns at execution:

cedric@dev _test $ python dbm.py
Traceback (most recent call last):
File "dbm.py", line 2, in ?
import anydbm
File "/usr/lib/python2.3/anydbm.py", line 59, in ?
_errors.append(_mod.error)
AttributeError: 'module' object has no attribute 'error'

Do you have any modules of your own creation called any of the following?

['dbhash', 'gdbm', 'dbm', 'dumbdbm']

These are the names of the modules anydbm tries to import, and it appears
to expect each of them to have an "error" name defined. Most likely your
module, with a conflicting name, is being found first and it does not
have an "error" attribute.

Generally speaking, you should try to avoid using the same names as
the standard library modules for your own code.

-Peter

 

[Paul McGuire]

Generally speaking, you should try to avoid using the same names as
the standard library modules for your own code.

This is an understandable limitation, but for new (and some not-so-new)
Python users, it is not always obvious what module names to avoid.

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

-- Paul

 

[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

 

[Peter Hansen]

This is an understandable limitation, but for new (and some not-so-new)
Python users, it is not always obvious what module names to avoid.

This gives a good summary: http://www.python.org/doc/current/modindex.html

I think the issue actually comes up relatively rarely. I say that partially
because problems stemming from this seem relatively infrequent in the
mailing list/newsgroup, and partly because the standard library modules
are fairly loosely coupled, and the issue above arose (I believe) only because
one standard library module was importing another which the user didn't
know would be imported, and it matched a name he had used.

Avoiding the basic ones, like "sys", "os", and "math", along with any that
you are actually importing elsewhere in your application will probably avoid
the issue 99% of the time.

-Peter