Uses PythonNet with current Python installation
I'm not sure why, but copying the PythonNet DLLs (CLR.dll and Python.Runtime.dll) to a standard CPython installation directory, does not give the CPython "real" access to the CLR. Two observations: 1. The CLR modules don't load on the first try (see output below), and 2. Running modules that require the CLR will sometimes fail (I'll investigate this some more). I've written a .Net backend for matplotlib, which runs fine with the Python distribution from PythonNet (Brian's distribution), but it crashes when the DLLs are in the CPython distribution from Python.org. I'm stumped. could it be related to the "loading delay" above? Any ideas? --- Output from CPython with PythonNet DLLs in the directory -------- C:\Python\Python2.3.3>python Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import os
os.system('dir *.dll')
Volume in drive C has no label. Volume Serial Number is 7CEC-BD8B Directory of C:\Python\Python2.3.3 09/08/2004 09:48 PM 2,560 CLR.dll 09/08/2004 09:47 PM 98,304 Python.Runtime.dll 12/18/2003 08:22 PM 974,915 python23.dll 3 File(s) 1,075,779 bytes 0 Dir(s) 13,137,387,520 bytes free 0
from CLR.System import String
getattr: proxy getattr: dict getattr: __path__ Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named System
from CLR.System import String
mystr = String('fubar')
mystr
<CLR.System.String object at 0x008E5D10>
Thane Plummer, Ph.D. CEO Magna Capital, LLC (520) 760-4957 (520) 405-2277 (cell) thane@magna-capital.com www.magna-capital.com
thane@magna-capital.com wrote:
I’m not sure why, but copying the PythonNet DLLs (CLR.dll and Python.Runtime.dll) to a standard CPython installation directory, does not give the CPython “real” access to the CLR.
Two observations:
1. The CLR modules don’t load on the first try (see output below), and
2. Running modules that require the CLR will sometimes fail (I’ll investigate this some more). I’ve written a .Net backend for matplotlib, which runs fine with the Python distribution from PythonNet (Brian’s distribution), but it crashes when the DLLs are in the CPython distribution from Python.org. I’m stumped… could it be related to the “loading delay” above?
Any ideas?
IIRC one (and only one) of them should be in DLLs directory. HTH Niki Spahiev
Hello, I'm not shure why, but importing CLR-modules requires that the top-module is imported first, then submodules of it. Try the following : import CLR import CLR.System from CLR.System import String as CLRString foo = CLRString('bar') print foo -- <CLR.System.String object at 0x008FF7D0> I guess that the first time you import String only CLR or CLR.System is actually imported. Kind regards, Florian Kintzel thane@magna-capital.com wrote:
I'm not sure why, but copying the PythonNet DLLs (CLR.dll and Python.Runtime.dll) to a standard CPython installation directory, does not give the CPython "real" access to the CLR.
Two observations:
1. The CLR modules don't load on the first try (see output below), and
2. Running modules that require the CLR will sometimes fail (I'll investigate this some more). I've written a .Net backend for matplotlib, which runs fine with the Python distribution from PythonNet (Brian's distribution), but it crashes when the DLLs are in the CPython distribution from Python.org. I'm stumped... could it be related to the "loading delay" above?
Any ideas?
--- Output from CPython with PythonNet DLLs in the directory --------
C:\Python\Python2.3.3>python
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
import os
os.system('dir *.dll')
Volume in drive C has no label.
Volume Serial Number is 7CEC-BD8B
Directory of C:\Python\Python2.3.3
09/08/2004 09:48 PM 2,560 CLR.dll
09/08/2004 09:47 PM 98,304 Python.Runtime.dll
12/18/2003 08:22 PM 974,915 python23.dll
3 File(s) 1,075,779 bytes
0 Dir(s) 13,137,387,520 bytes free
0
from CLR.System import String
getattr: proxy
getattr: dict
getattr: __path__
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: No module named System
from CLR.System import String
mystr = String('fubar')
mystr
<CLR.System.String object at 0x008E5D10>
Thane Plummer, Ph.D.
CEO Magna Capital, LLC
(520) 760-4957
(520) 405-2277 (cell)
thane@magna-capital.com <mailto:thane@magna-capital.com>
www.magna-capital.com <http://www.magna-capital.com>
------------------------------------------------------------------------
_________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
It's a bootstrapping problem. The CLR module not only defines the namespace for .NET packages, but also registers the import hook for those packages. So, without the "import CLR", the subpackage name cannot be found at the time when the first name lookup occurs. The import hook can, and probably should be written in Python, to avoid the bootstrapping problem. It would delegate to C# for CLR package references. Bruce ----- "f.kintzel" <f.kintzel@internet-access.de> wrote in message news:4157CD2F.5010501@internet-access.de... Hello, I'm not shure why, but importing CLR-modules requires that the top-module is imported first, then submodules of it. Try the following : import CLR import CLR.System from CLR.System import String as CLRString foo = CLRString('bar') print foo
participants (4)
-
Bruce Dodson -
f.kintzel -
Niki Spahiev -
thane＠magna-capital.com