Python or Windows seems to have trouble importing DLLs when inside packages. I'm working on an extension which pulls in a DLL gmp31.dll which lives inside a package dir mx/Number/mxNumber along side the Python wrapper extension mxNumber.pyd. Currently, I'm using this code in the subpackage's __init__.py: # On Windows we also distribute the GMP DLL (in the win32 subdir). To # have Win32 find the DLL we need to be explicit about the path in # sys.path though. This trick works for all startup directories # *except* \PythonXX (for some reason this fails), but is not thread # safe... import sys, os if sys.platform[:3] == 'win': abspath = os.path.abspath(__path__[0]) sys.path.insert(0, abspath) from mxNumber import * sys.path.remove(abspath) else: from mxNumber import * I don't have any clue why the import works from everywhere *except* the Python21 install directory... anyone does ? Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
Sorry for the delay -- I had a hard time understanding what this writeup meant, so had to download the package and try it. [M.-A. Lemburg]
Concretely, I have these files now, under my Python 2.1 installation directory: C:\Python21>dir/b/on mx\Number\mxNumber gmp31.dll mxNumber.pyd mxNumber.h test.py __init__.py C:\Python21>
Currently, I'm using this code in the subpackage's __init__.py:
And by "the subpackage" here I believe you mean the tail-end mxNumber directory, previously called "a package". IOW, you're talking specifically about \Python21\mx\Number\mxNumber\__init__.py If you meant something else, scream.
I don't have any clue why the import works
Which import are you talking about? Please show exactly what you do that fails -- I haven't been able to find any problem here. For example, I replaced \Python21\mx\Number\mxNumber\__init__.py which contains the code you showed above, with this two-liner: from mxNumber import * from mxNumber import __version__ Having done that, here's a shell session started in the installation directory, and after a reboot "just to make sure": C:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
So nothing failed. What do *you* do that fails? Here's another session started from a "random" directory: C:\Code>\python21\python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
Same thing.
from everywhere *except* the Python21 install directory...
It would more helpful to name a specific directory than to make an untrue claim <wink -- but you didn't try every directory other than Python21, and the specific directories you actually did try may be important>. BTW, it's a mondo cool package! I had a lot of fun with it. But then I was able to, since I stopped trying to guess what your problem was <wink>. What's up? I was running Win98SE in the above, but that shouldn't make a difference. Perhaps, during development, you left crap sitting around in your installation directory that's confusing your attempts to import things? If not, please be very explicit about what you do that fails, and what "fails" means (crash, ImportError, Windows error box, ...?).
Tim Peters wrote:
Sorry for the delay -- I had a hard time understanding what this writeup meant, so had to download the package and try it.
Oh, sorry that I wasn't clear enough. Referring to the mxNumber package, I am seeing this situation: # This works... (note the start directory) C:\WINDOWS>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
# This doesn't.... (from the Python install directory) D:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
# OTOH, this works.... (one level below the Python install directory) D:\Python21>cd mx D:\Python21\mx>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
import mx.Number
Right.
Hmm, you are right, it does work for me too (I wonder why I thought it failed without the sys.path tweaking... probably just tested from the Python install dir): C:\WINDOWS>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
D:\Python21\mx>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
D:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
Ok, ok ;-) Please try starting Python from your Python install dir and then do the import. BTW, I'm doing this on Windows 95 in case this matters (which I'm sure it does :-/).
BTW, it's a mondo cool package! I had a lot of fun with it.
Thanks :)
"fail" means that Python cannot find the gmp31.dll sitting right next to the mxNumber.pyd in the same directory. This should normally work, but somehow doesn't when Python is started from the install dir:
[MAL]
Oh, sorry that I wasn't clear enough.
Me neither (see below).
Well, there's your problem: looks some German hackers got into your machine and screwed up the OS <wink>. Now let me clarify what I wrote before: when I said I couldn't provoke a problem, I meant ANY problem. It didn't matter whether I used the __init__.py you shipped, or used the two-liner I posted, and it didn't matter whether I started Python 2.1 from the install directory or from C:\Code (etc). Nothing failed no matter what I tried. The only thing I see different in what you did above is that your Python install directory is on a different drive (D: instead of C:). I only have one drive here, so I can't do a good job of simulating that. Best I can do here is fake it via the DOS subst command: K:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
import mx.Number from mx.Number import *
Still no problem. What happens if you install Python onto your C: drive instead? And if that does work for you, is it because of the C: drive, or because you left some old development work on your D: drive that's confusing things? Do you have confirmation of your problem from anyone else? Or are you the only one who has bumped into it?
I already had, in the last msg. And again above.
BTW, I'm doing this on Windows 95 in case this matters (which I'm sure it does :-/).
Possibly, but can't say. We need more data. BTW, do you understand what your code does <0.7 wink>? That is, there are packages, modules *and* DLLs with the same base name, and "import *" everywhere. I've always stayed so far away from import end cases that I have no idea what the rules are supposed to be when you live on the edge. That may have something to do with this too, although I can't see how (although since I don't know what the rules are, that's a guess too!).
Tim Peters wrote:
Could be...
OK. I tried the same on a Win98 box with a fresh Python and mxNumber install -- and found no problems either; which leaves me rather clueless about where the failures on my Win95 box originate. Could someone else with a Win95 box perhaps test this ? Thanks anyway for hanging on, -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
I see the same Behaviour as Marc-Andre: Traceback in Win95 (running under VMWare, running under Win2k). C:\WINDOWS>\python21\python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
C:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
Windows 95. [Version 4.00.950] C:\Python21> Marc-Andre, what about other python versions? Thomas
Thomas Heller wrote:
mxNumber needs Python 2.1, so I have no way of testing it under Python 2.0. Both imports work on Winows 98SE, so I guess this has something to do with Win95 no handling imports using relative paths correctly (if you run Python with -vv you'll see that Python searches using relative paths when started from C:\Python21). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
Sorry for the delay -- I had a hard time understanding what this writeup meant, so had to download the package and try it. [M.-A. Lemburg]
Concretely, I have these files now, under my Python 2.1 installation directory: C:\Python21>dir/b/on mx\Number\mxNumber gmp31.dll mxNumber.pyd mxNumber.h test.py __init__.py C:\Python21>
Currently, I'm using this code in the subpackage's __init__.py:
And by "the subpackage" here I believe you mean the tail-end mxNumber directory, previously called "a package". IOW, you're talking specifically about \Python21\mx\Number\mxNumber\__init__.py If you meant something else, scream.
I don't have any clue why the import works
Which import are you talking about? Please show exactly what you do that fails -- I haven't been able to find any problem here. For example, I replaced \Python21\mx\Number\mxNumber\__init__.py which contains the code you showed above, with this two-liner: from mxNumber import * from mxNumber import __version__ Having done that, here's a shell session started in the installation directory, and after a reboot "just to make sure": C:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
So nothing failed. What do *you* do that fails? Here's another session started from a "random" directory: C:\Code>\python21\python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
Same thing.
from everywhere *except* the Python21 install directory...
It would more helpful to name a specific directory than to make an untrue claim <wink -- but you didn't try every directory other than Python21, and the specific directories you actually did try may be important>. BTW, it's a mondo cool package! I had a lot of fun with it. But then I was able to, since I stopped trying to guess what your problem was <wink>. What's up? I was running Win98SE in the above, but that shouldn't make a difference. Perhaps, during development, you left crap sitting around in your installation directory that's confusing your attempts to import things? If not, please be very explicit about what you do that fails, and what "fails" means (crash, ImportError, Windows error box, ...?).
Tim Peters wrote:
Sorry for the delay -- I had a hard time understanding what this writeup meant, so had to download the package and try it.
Oh, sorry that I wasn't clear enough. Referring to the mxNumber package, I am seeing this situation: # This works... (note the start directory) C:\WINDOWS>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
# This doesn't.... (from the Python install directory) D:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
# OTOH, this works.... (one level below the Python install directory) D:\Python21>cd mx D:\Python21\mx>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
import mx.Number
Right.
Hmm, you are right, it does work for me too (I wonder why I thought it failed without the sys.path tweaking... probably just tested from the Python install dir): C:\WINDOWS>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
D:\Python21\mx>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
D:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
Ok, ok ;-) Please try starting Python from your Python install dir and then do the import. BTW, I'm doing this on Windows 95 in case this matters (which I'm sure it does :-/).
BTW, it's a mondo cool package! I had a lot of fun with it.
Thanks :)
"fail" means that Python cannot find the gmp31.dll sitting right next to the mxNumber.pyd in the same directory. This should normally work, but somehow doesn't when Python is started from the install dir:
[MAL]
Oh, sorry that I wasn't clear enough.
Me neither (see below).
Well, there's your problem: looks some German hackers got into your machine and screwed up the OS <wink>. Now let me clarify what I wrote before: when I said I couldn't provoke a problem, I meant ANY problem. It didn't matter whether I used the __init__.py you shipped, or used the two-liner I posted, and it didn't matter whether I started Python 2.1 from the install directory or from C:\Code (etc). Nothing failed no matter what I tried. The only thing I see different in what you did above is that your Python install directory is on a different drive (D: instead of C:). I only have one drive here, so I can't do a good job of simulating that. Best I can do here is fake it via the DOS subst command: K:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
import mx.Number from mx.Number import *
Still no problem. What happens if you install Python onto your C: drive instead? And if that does work for you, is it because of the C: drive, or because you left some old development work on your D: drive that's confusing things? Do you have confirmation of your problem from anyone else? Or are you the only one who has bumped into it?
I already had, in the last msg. And again above.
BTW, I'm doing this on Windows 95 in case this matters (which I'm sure it does :-/).
Possibly, but can't say. We need more data. BTW, do you understand what your code does <0.7 wink>? That is, there are packages, modules *and* DLLs with the same base name, and "import *" everywhere. I've always stayed so far away from import end cases that I have no idea what the rules are supposed to be when you live on the edge. That may have something to do with this too, although I can't see how (although since I don't know what the rules are, that's a guess too!).
Tim Peters wrote:
Could be...
OK. I tried the same on a Win98 box with a fresh Python and mxNumber install -- and found no problems either; which leaves me rather clueless about where the failures on my Win95 box originate. Could someone else with a Win95 box perhaps test this ? Thanks anyway for hanging on, -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
I see the same Behaviour as Marc-Andre: Traceback in Win95 (running under VMWare, running under Win2k). C:\WINDOWS>\python21\python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
C:\Python21>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
Windows 95. [Version 4.00.950] C:\Python21> Marc-Andre, what about other python versions? Thomas
Thomas Heller wrote:
mxNumber needs Python 2.1, so I have no way of testing it under Python 2.0. Both imports work on Winows 98SE, so I guess this has something to do with Win95 no handling imports using relative paths correctly (if you run Python with -vv you'll see that Python searches using relative paths when started from C:\Python21). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
participants (3)
-
M.-A. Lemburg -
Thomas Heller -
Tim Peters