Mailman 3 October 2014 - Python.NET

cx_freeze and python.net
by Boris Burdin 21 May '17

21 May '17

Hello everybody, I'm trying to build a python.net application using cx-freeze . Once the application is built, I put in my final folder the Python.Runtime.dll. but it stil doesn't seem to work . Actually, when I run the .exe file, nothing is happening. So, I wonder if there were something else to do, another dll to put in the folder, or any option to use with cx_freeze when building the application ? i would be very grateful if you could help me on this matter .. Thanks in advance, Boris

3 2

Efficient copy of .NET Array to ctypes or numpy array
by Nikhil Garg 20 Nov '14

20 Nov '14

Hi, I have looked at the following thread to copy a c# array to numpy list using python dot net. https://mail.python.org/pipermail/pythondotnet/2014-May/001525.html When I try the methods mentioned in the complete thread I manage to get the array from simple iteration method or np.fromiter, but I have not been able to make GCHandle or Marshal.Copy work for my case. To explain about my issue, I use a computer code written in c# which produces output in a custom build format. I am able to access the data from the file system using python dot net, but it seems that it take almost half an hour to get the data from the file. For example my file has an array of size 5018x73x400, if i use *fromiter, *i provide the last bit of array to copy to python due to the way file stores output. for j in xrange(num_nodes-1): for i in xrange(nsteps): temp = file_in.ReadItemTimeStep(j+1,i).Data temp_1 = np.fromiter(temp, float) dest[j, i] = temp_1 Other way of doing same task would be to use a for loop but tht would be really slow. for k in xrange(num_nodes-1): for k in xrange(nsteps): for i in xrange(nvals): temp[k,j,i] = file_in.ReadItemTimeStep(k+1, j).Data[i] I am trying to find a faster way to extract the data from the file. I was wondering if there is a possibility to use something like GChandle or Marshal.Copy. I have also attached same output from Marshal.Copy Marshal.Copy(temp, 0, IntPtr.__overloads__[int](temp2.__array_interface__['data'][0]), len(temp)) 0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 3.13551399e-242, 4.20993645e-161, 8.71245319e-119, 8.38370432e-089, 2.60762781e-075, 1.92616374e-072, 2.89006184e-072, 3.06007265e-082, 3.81879776e-315, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.03959661e-297, 7.22038448e-196, 3.05237954e-130, 2.58469346e-093, 2.29495911e-070, 3.74354820e-062, 1.74288060e-061, 2.13172553e-067, 2.74305386e-077, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.02484756e-240, 1.70193770e-154, 1.30625320e-108, 1.16793762e-075, 2.96889340e-061, 7.84687103e-058, 1.16879604e-057, 5.56256478e-068, 4.06437857e-315, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.11705239e-296, 1.46978156e-194, 1.98034372e-128, 3.79615170e-091, 5.88936509e-068, 1.85305929e-059, 2.16186001e-058, Whereas the actual values stored in the array are 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 5.66641200e-37, 1.24961600e-30, 5.34846800e-25, 1.72519600e-20, 1.49402200e-17, 3.27685300e-15, 4.10687500e-13, 1.87978200e-11, 2.01397900e-10, 8.83561100e-10, 2.14397600e-09, 2.02600300e-09, 2.47599800e-09, 2.15987100e-09, 4.82694100e-10, 1.18759300e-10, 3.32024100e-11, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 1.45288600e-37, 7.37245900e-31, 7.59282500e-25, 5.85463400e-20, 1.20634700e-16, 3.06414300e-14, 5.16041300e-12, 2.87562800e-10, 3.62841500e-09, 1.63540600e-08, 4.06988300e-08, 3.97764200e-08, 4.88768500e-08, 4.07385000e-08, 8.78868600e-09, I would appreciate any help i can get regarding this matter. Nikhil

5 11

binding redirects
by Adam Klein 23 Oct '14

23 Oct '14

Hi all, I recently had a situation where I wanted to redirect FSharp.Core.dll from 4.3.0.0 to 4.3.1.0 during Python.NET assembly loading, and the only way I could figure out how to do so was machine-wide via the machine.config in the .NET framework. I looked at the Python.NET source code and I'm fairly confident you can't do this at the "application" level right now, but I just wanted to ask anyway. Would be a nice feature to have, not sure it's possible with the current Load/LoadFrom assembly loading semantics? Best, Adam

1 0

glibc invalid pointer when importing clr
by zaripov＠electronxray.com 18 Oct '14

18 Oct '14

Hi! First, sorry for my English. I'm trying to use pythonnet on Debian Wheezy. I'm checkout svn trunk, when install mono-2, and other dependencies. Building clr.so done without errors. On the next step I'm put clr.so, Python.Runtime.dll and Python.Runtime.dll.config in /usr/local/lib/python2.7/dist-packages. But when I'm try to use this, I'm got such traceback: root@debian-salt:/usr/local/lib/python2.7/dist-packages# python Python 2.7.3 (default, Mar 14 2014, 11:57:14) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import clr *** glibc detected *** python: free(): invalid pointer: 0xb6653180 *** ======= Backtrace: ========= /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70c41)[0xb7618c41] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x724a8)[0xb761a4a8] /lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb761d5ed] /usr/lib/libpython2.7.so.1.0(PyString_InternInPlace+0xaf)[0xb6e3f7af] ======= Memory map: ======== 00010000-00081000 rw-p 00000000 00:00 0 08048000-0828e000 r-xp 00000000 08:05 23939 /usr/bin/python2.7 0828e000-0828f000 r--p 00245000 08:05 23939 /usr/bin/python2.7 0828f000-082e4000 rw-p 00246000 08:05 23939 /usr/bin/python2.7 082e4000-082f1000 rw-p 00000000 00:00 0 09e7a000-09fec000 rw-p 00000000 00:00 0 [heap] b6500000-b6521000 rw-p 00000000 00:00 0 b6521000-b6600000 ---p 00000000 00:00 0 b6652000-b6693000 rw-p 00000000 00:00 0 b6693000-b66ae000 r--p 00000000 08:05 46606 /usr/local/lib/python2.7/dist-packages/Python.Runtime.dll b66ae000-b66b7000 ---p 00000000 00:00 0 b66b7000-b67b0000 rw-p 00000000 00:00 0 b67b0000-b67cf000 ---p 00000000 00:00 0 b67cf000-b67e0000 rwxp 00000000 00:00 0 b67e0000-b67ea000 r-xp 00000000 08:01 32537 /lib/i386-linux-gnu/i686/cmov/libnss_files-2.13.so b67ea000-b67eb000 r--p 00009000 08:01 32537 /lib/i386-linux-gnu/i686/cmov/libnss_files-2.13.so b67eb000-b67ec000 rw-p 0000a000 08:01 32537 /lib/i386-linux-gnu/i686/cmov/libnss_files-2.13.so b67ec000-b67f5000 r-xp 00000000 08:01 32539 /lib/i386-linux-gnu/i686/cmov/libnss_nis-2.13.so b67f5000-b67f6000 r--p 00008000 08:01 32539 /lib/i386-linux-gnu/i686/cmov/libnss_nis-2.13.so b67f6000-b67f7000 rw-p 00009000 08:01 32539 /lib/i386-linux-gnu/i686/cmov/libnss_nis-2.13.so b67f7000-b680a000 r-xp 00000000 08:01 32533 /lib/i386-linux-gnu/i686/cmov/libnsl-2.13.so b680a000-b680b000 r--p 00012000 08:01 32533 /lib/i386-linux-gnu/i686/cmov/libnsl-2.13.so b680b000-b680c000 rw-p 00013000 08:01 32533 /lib/i386-linux-gnu/i686/cmov/libnsl-2.13.so b680c000-b680e000 rw-p 00000000 00:00 0 b6814000-b6818000 rw-p 00000000 00:00 0 b6818000-b681a000 r-xp 00000000 08:05 10456 /usr/lib/i386-linux-gnu/gconv/UTF-16.so b681a000-b681b000 r--p 00001000 08:05 10456 /usr/lib/i386-linux-gnu/gconv/UTF-16.so b681b000-b681c000 rw-p 00002000 08:05 10456 /usr/lib/i386-linux-gnu/gconv/UTF-16.so b681c000-b6a96000 r--p 00000000 08:05 41796 /usr/lib/mono/2.0/mscorlib.dll b6a96000-b6aa7000 rwxp 00000000 00:00 0 b6aa7000-b6ae4000 r-xp 00000000 08:01 33080 /lib/i386-linux-gnu/libpcre.so.3.13.1 b6ae4000-b6ae5000 rw-p 0003c000 08:01 33080 /lib/i386-linux-gnu/libpcre.so.3.13.1 b6ae5000-b6bc5000 r-xp 00000000 08:05 4041 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 b6bc5000-b6bc9000 r--p 000e0000 08:05 4041 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 b6bc9000-b6bca000 rw-p 000e4000 08:05 4041 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 b6bca000-b6bd1000 rw-p 00000000 00:00 0 b6bd1000-b6ccc000 r-xp 00000000 08:01 33092 /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4 b6ccc000-b6ccd000 r--p 000fa000 08:01 33092 /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4 b6ccd000-b6cce000 rw-p 000fb000 08:01 33092 /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4 b6cce000-b6f39000 r-xp 00000000 08:05 38605 /usr/lib/libpython2.7.so.1.0 b6f39000-b6f3a000 r--p 0026b000 08:05 38605 /usr/lib/libpython2.7.so.1.0 b6f3a000-b6f8f000 rw-p 0026c000 08:05 38605 /usr/lib/libpython2.7.so.1.0 b6f8f000-b6f9c000 rw-p 00000000 00:00 0 b6f9c000-b6fa3000 r-xp 00000000 08:01 32543 /lib/i386-linux-gnu/i686/cmov/librt-2.13.so b6fa3000-b6fa4000 r--p 00006000 08:01 32543 /lib/i386-linux-gnu/i686/cmov/librt-2.13.so b6fa4000-b6fa5000 rw-p 00007000 08:01 32543 /lib/i386-linux-gnu/i686/cmov/librt-2.13.so b6fa5000-b72b6000 r-xp 00000000 08:05 41753 /usr/lib/libmono-2.0.so.1.0.0 b72b6000-b72b9000 r--p 00310000 08:05 41753 /usr/lib/libmono-2.0.so.1.0.0 b72b9000-b72be000 rw-p 00313000 08:05 41753 /usr/lib/libmono-2.0.so.1.0.0 b72be000-b72dd000 rw-p 00000000 00:00 0 b72de000-b72e4000 r-xp 00000000 08:01 32535 /lib/i386-linux-gnu/i686/cmov/libnss_compat-2.13.so b72e4000-b72e5000 r--p 00005000 08:01 32535 /lib/i386-linux-gnu/i686/cmov/libnss_compat-2.13.so b72e5000-b72e6000 rw-p 00006000 08:01 32535 /lib/i386-linux-gnu/i686/cmov/libnss_compat-2.13.so b72e6000-b72e7000 rw-s 00000000 00:11 939641 /run/shm/mono.7877 b72e7000-b72eb000 rw-p 00000000 00:00 0 b72eb000-b7308000 r-xp 00000000 08:01 32559 /lib/i386-linux-gnu/libtinfo.so.5.9 b7308000-b730a000 r--p 0001c000 08:01 32559 /lib/i386-linux-gnu/libtinfo.so.5.9 b730a000-b730b000 rw-p 0001e000 08:01 32559 /lib/i386-linux-gnu/libtinfo.so.5.9 b730b000-b7343000 r-xp 00000000 08:01 32576 /lib/i386-linux-gnu/libreadline.so.6.2 b7343000-b7344000 r--p 00038000 08:01 32576 /lib/i386-linux-gnu/libreadline.so.6.2 b7344000-b7347000 rw-p 00039000 08:01 32576 /lib/i386-linux-gnu/libreadline.so.6.2 b7347000-b7349000 rw-p 00000000 00:00 0 b7349000-b734d000 r-xp 00000000 08:05 24426 /usr/lib/python2.7/lib-dynload/readline.so b734d000-b734e000 r--p 00003000 08:05 24426 /usr/lib/python2.7/lib-dynload/readline.so b734e000-b734f000 rw-p 00004000 08:05 24426 /usr/lib/python2.7/lib-dynload/readline.so b734f000-b74c6000 r--p 00000000 08:05 6381 /usr/lib/locale/locale-archive b74c6000-b758b000 rw-p 00000000 00:00 0 b758b000-b75a7000 r-xp 00000000 08:01 32523 /lib/i386-linux-gnu/libgcc_s.so.1 b75a7000-b75a8000 rw-p 0001b000 08:01 32523 /lib/i386-linux-gnu/libgcc_s.so.1 b75a8000-b7705000 r-xp 00000000 08:01 32527 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so b7705000-b7707000 r--p 0015d000 08:01 32527 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so b7707000-b7708000 rw-p 0015f000 08:01 32527 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so b7708000-b770b000 rw-p 00000000 00:00 0 b770b000-b772f000 r-xp 00000000 08:01 32531 /lib/i386-linux-gnu/i686/cmov/libm-2.13.so b772f000-b7730000 r--p 00023000 08:01 32531 /lib/i386-linux-gnu/i686/cmov/libm-2.13.so b7730000-b7731000 rw-p 00024000 08:01 32531 /lib/i386-linux-gnu/i686/cmov/libm-2.13.so b7731000-b7748000 r-xp 00000000 08:01 32615 /lib/i386-linux-gnu/libz.so.1.2.7 b7748000-b7749000 r--p 00016000 08:01 32615 /lib/i386-linux-gnu/libz.so.1.2.7Stacktrace: at (wrapper managed-to-native) Python.Runtime.Runtime.Py_Initialize () <0xffffffff> at Python.Runtime.Runtime.Initialize () <0x00013> at Python.Runtime.PythonEngine.Initialize () <0x00047> at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: /usr/lib/libmono-2.0.so.1(+0xb5b43) [0xb705ab43] [0xb777c410] [0xb777c422] /lib/i386-linux-gnu/i686/cmov/libc.so.6(gsignal+0x51) [0xb75d2681] /lib/i386-linux-gnu/i686/cmov/libc.so.6(abort+0x182) [0xb75d5ab2] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x66b55) [0xb760eb55] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70c41) [0xb7618c41] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x724a8) [0xb761a4a8] /lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d) [0xb761d5ed] /usr/lib/libpython2.7.so.1.0(PyString_InternInPlace+0xaf) [0xb6e3f7af] Debug info from gdb: ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Mono 2.10.8.1-8 libglib2.0-dev 2.33.12+really2.32.4-5 Have any suggestions how to fix this? Help very welcome! Best regards, Renat Zaripov

2 2

import Python module in C# - multiple instances, not global/static for the class
by Denis Akhiyarov 07 Oct '14

07 Oct '14

Is there any way to import the same Python module as multiple instances, e.g. for each instance of C# class/object? For now it looks like the same module is imported for each instance of C# object (essentially a static Python object) when I do this: using (Py.GIL()) { dynamic syspy = Py.Import("sys"); syspy.path.append(ConfigDirectory); mymodulepy= Py.Import("mymodulepy"); }

1 1

How to embed properly using Python for .NET
by Denis Akhiyarov 06 Oct '14

06 Oct '14

When I try to use PythonEngine.ImportModule(mymodulename) some of the optional modules in dependencies are attempted to be loaded (not required for module use without embedding). This results in return null from this method because some of these optional dependencies are not required and hence not available. What is the proper method to use in this PythonNET API for loading user-written module which depends on multiple other modules? I tried importhook.cs from both versions: https://github.com/pythonnet/pythonnet https://github.com/renshawbay/pythonnet http://stackoverflow.com/questions/25101718/how-to-embed-properly-using-pyt…

2 3

Python.Net for Python3: bug when using an embedded interpreter
by Serge WEINSTOCK 01 Oct '14

01 Oct '14

Hi Tony, You recently made a change which prevents me using the library in an embedded Python interpreter. In pythonengine.cs, you "inject" decorators with the following code: //================================================================= public static void Initialize() { ..... IntPtr globals = Runtime.PyEval_GetGlobals(); PyDict locals = new PyDict(); try { IntPtr builtins = Runtime.PyEval_GetBuiltins(); Runtime.PyDict_SetItemString(locals.Handle, "__builtins__", builtins); var assembly = Assembly.GetExecutingAssembly(); using (Stream stream = assembly.GetManifestResourceStream("Python.Runtime.resources.clr.py")) using (StreamReader reader = new StreamReader(stream)) { // add the contents of clr.py to the module string clr_py = reader.ReadToEnd(); PyObject result = RunString(clr_py, globals, locals.Handle); if (null == result) throw new PythonException(); result.Dispose(); } //================================================================= When running from a Python script, it's fine because the Python interpreter has already been initialized and global variables have been defined. The issue is that when running from an embedded interpreter. As I must first initialize the Python engine using PythonEngine.Initialize(). So when we reach this piece of code, there is no script running, no "Python context", so "PyEval_GetGlobals" returns null and "RunString" fails. We could create an artificial global dictionary but it won't be available to the rest of the code. I think it should be best to move this code into a Python module. If run from a script (PyEval_GetGlobals() != null), you could inject the decorators with a simple "from decorators_pythonnet import *". If run from an embedded interpreter, we could add a line for running the same code once the engine has been initialized. What do you think? Serge Weinstock ___________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited. Please refer to http://www.bnpparibas.co.uk/en/email-disclaimer/ for additional disclosures.

2 3