Hey, get this! [was: import from database]

Steve Holden steve at holdenweb.com
Sat Jan 29 20:40:30 EST 2005


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 ...

sholden at dellboy ~/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"


sholden at dellboy ~/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



More information about the Python-list mailing list