Peter Otten wrote:
Steve Holden wrote:
This is even stranger: it makes it if I import the module a second time:
[second import seems to succeed]
Maybe you are experiencing some version confusion? What you describe looks much like the normal Python 2.3 behaviour (with no import hook involved) whereas you seem to operate on the 2.4 library. A partially initialized module object is left behind in sys.modules and seen by further import attempts.
I agree that this is 2.3-like behavior, but Python cannot lie ...
[EMAIL PROTECTED] ~/Projects/Python/dbimp $ python Python 2.4 (#1, Dec 4 2004, 20:10:33) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>>
$ cat arbitrary.py
import not_there
def f(): print "you ain't gonna see that"
$ python Python 2.3.3 (#1, Apr 6 2004, 01:47:39) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import arbitrary
Traceback (most recent call last): File "<stdin>", line 1, in ? File "arbitrary.py", line 2, in ? import not_there ImportError: No module named not_there
import arbitrary arbitrary.f()
Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'f'
I have no experience with import hooks, but for normal imports that has been fixed in Python 2.4:
$ py24 Python 2.4 (#5, Jan 4 2005, 10:14:01) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import arbitrary
Traceback (most recent call last): File "<stdin>", line 1, in ? File "arbitrary.py", line 2, in ? import not_there ImportError: No module named not_there
import arbitrary
Traceback (most recent call last): File "<stdin>", line 1, in ? File "arbitrary.py", line 2, in ? import not_there ImportError: No module named not_there
Peter
$ cat arbitrary.py import not_there
def f():
print "you ain't gonna see that"
[EMAIL PROTECTED] ~/Projects/Python/dbimp $ python Python 2.4 (#1, Dec 4 2004, 20:10:33) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import arbitrary Traceback (most recent call last): File "<stdin>", line 1, in ? File "arbitrary.py", line 1, in ? import not_there ImportError: No module named not_there >>> import arbitrary Traceback (most recent call last): File "<stdin>", line 1, in ? File "arbitrary.py", line 1, in ? import not_there ImportError: No module named not_there >>>
Yup, looks like 2.4 (despite this funny cygwin stuff, could that make a difference).
Let me try it under Windows [ferkle, ferkle ...]
Does the same thing there.
This problem also seems to depend what's already loaded. I wrote a program to write a test program that looks like this:
import dbimp dbimp.install()
print "Trying aifc"
try:
import aifc
except:
print "%Failed: aifc"
print "Trying anydbm" try: import anydbm except: print "%Failed: anydbm"
print "Trying asynchat" try: import asynchat except: print "%Failed: asynchat"
...
import dbimp dbimp.install()
print "Trying aifc"
try:
import aifc
except:
print "%Failed: aifc"
print "Trying anydbm" try: import anydbm except: print "%Failed: anydbm"
print "Trying asynchat" try: import asynchat except: print "%Failed: asynchat"
The two platforms give expectedly close results. I'm storing compiled code, so a version incompatibility would be a problem, I agree, but I have checked the program that loaded the database, and loaded it again from the Windows source rather than the CygWin source, just to see whether there were any unnoticed platform dependencies. The results were exactly the same using either library, and Windows and Cygwin showed only minor variations.
exhaustCyg24.txt:%Failed: bsddb.dbtables exhaustCyg24.txt:%Failed: bsddb.test.test_all exhaustCyg24.txt:%Failed: bsddb.test.test_associate exhaustCyg24.txt:%Failed: bsddb.test.test_basics exhaustCyg24.txt:%Failed: bsddb.test.test_compat exhaustCyg24.txt:%Failed: bsddb.test.test_dbobj exhaustCyg24.txt:%Failed: bsddb.test.test_dbshelve exhaustCyg24.txt:%Failed: bsddb.test.test_dbtables exhaustCyg24.txt:%Failed: bsddb.test.test_env_close exhaustCyg24.txt:%Failed: bsddb.test.test_get_none exhaustCyg24.txt:%Failed: bsddb.test.test_join exhaustCyg24.txt:%Failed: bsddb.test.test_lock exhaustCyg24.txt:%Failed: bsddb.test.test_misc exhaustCyg24.txt:%Failed: bsddb.test.test_queue exhaustCyg24.txt:%Failed: bsddb.test.test_recno exhaustCyg24.txt:%Failed: bsddb.test.test_thread exhaustCyg24.txt:%Failed: tzparse exhaustWin24.txt:%Failed: bsddb.dbtables exhaustWin24.txt:%Failed: bsddb.test.test_all exhaustWin24.txt:%Failed: bsddb.test.test_associate exhaustWin24.txt:%Failed: bsddb.test.test_basics exhaustWin24.txt:%Failed: bsddb.test.test_compat exhaustWin24.txt:%Failed: bsddb.test.test_dbobj exhaustWin24.txt:%Failed: bsddb.test.test_dbshelve exhaustWin24.txt:%Failed: bsddb.test.test_dbtables exhaustWin24.txt:%Failed: bsddb.test.test_env_close exhaustWin24.txt:%Failed: bsddb.test.test_get_none exhaustWin24.txt:%Failed: bsddb.test.test_join exhaustWin24.txt:%Failed: bsddb.test.test_lock exhaustWin24.txt:%Failed: bsddb.test.test_misc exhaustWin24.txt:%Failed: bsddb.test.test_queue exhaustWin24.txt:%Failed: bsddb.test.test_recno exhaustWin24.txt:%Failed: bsddb.test.test_thread exhaustWin24.txt:%Failed: pty exhaustWin24.txt:%Failed: rlcompleter exhaustWin24.txt:%Failed: tzparse
As a workaround I can for the moment just omit everything that show the least suspicion of not working from the database, but I'd really rather know what's failing.
If you have any clues I'd be grateful.
regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
