Mailman 3 April 2020 - Python.NET

Working group notes for Feb 27, 2020
by Mark Visser 21 May '20

21 May '20

Attendees: Victor, Mark, Benedikt, Benoit, Amos, Felix Agenda Review action items from last meeting: Benoit to finish wiki page for threading Victor will talk to Benedikt regarding creating a lib/separate repo for codecs (this also applies to QuantConnect) Quantconnect PR - Victor to ensure Amos commits are mirrored in master Amos should take over PR #1016 Victor will try to review #958 instead See if Benedikt needs better time or we can make decisions while he’s off Unity is settled on 2.4.0, and might reduce presence Create NuGet organization and transfer package ownership for NuGet package <https://www.nuget.org/packages/pythonnet/> At least 1 more person to admin NuGet org Mailing list for maintainers only A plan to replace IntPtr with the new reference types Upstreaming Lost Tech (Victor’s) fork Python 2 support? DllImport -> GetDelegateForFunctionPointer Notes Wiki page for threading is up in tutorials section Victor & Amos discussing failing multithreading test case in PR #1022 Looks like Amos's commits in the Quantconnect PR are already in master PR #1016 closed in favour of using PR #958 instead Slow going on PR #958 review needs some description to explain the changes - a few sentences that describe the intended effects of the changes: what actions are necessary to implement soft shutdown? hard to get overall picture of what the code is expected to do Regarding the time slot this is the best we can get that balances China, North America and Germany time zones it's OK for Victor make decisions in the meeting - unless Benedikt is completely against the decision, it will be OK NuGet org Victor has access problem is that registered e-mail is the mailing list e-mail, security hole A plan to replace IntPtr with the new reference types we should avoid using IntPtr in our own pull requests should use proper pointer types ourselves, once we've got good practices established can be documented belongs with Benedikt's work on loader PR Upstreaming Lost Tech (Victor’s) fork Python 2 support not handled, should we drop support from master (and move 2.x to branch)? DllImport -> GetDelegateForFunctionPointer change require dropping 2.x in general dropping 2.x helps with a lot of things not a problem for Unity, also moving to 3.x No arguments against dropping support for 2.x in master were raised is master in a good state for a last release of 2.x? have one last push to get any changes not specific to 3.x into master before branch-off / tag codecs other minor changes stability of current release? random CI failures we added more tests recently - e.g. domain reload tests unstable one of the domain reload tests often fails on Python 2.7 Amos' changes for normal mode shutdown should solve these failures - should we land them first? no, let's only backport them if there is demand master is currently green As soon as we have all PRs we want in, we will tag 2.4.1 (if no breaking changes, 2.5 otherwise) and branch if necessary will use a github milestone to track PRs for 2.4.1 Still failing tests on 3.8, but likely a dependency on 3.7 - next release should have 3.8 support Lost Tech branch has support for Python version independence (except for 3.8) complete version independence requires dynamic tp slot handling will need runtime logic for handling different versions of Python to handle differing slot locations also need to remove PInvoke usage solving for these two issues will allow any Python version to be used at runtime instead of requiring pre-build for specific versions Lost Tech branch doesn't handle embedding C# in Python, but CLR loader PR should take care of this - already working, and should work with Lost Tech branch changes Dynamic CLR loading won't support 2.4 Action Items Victor will create codecs repo on github Amos to create issue or PR to make implicit operator for reference types to convert reference to IntPtr Amos will create wiki page to explain soft shutdown Benedikt will look into creating a private mailing list for maintainers only Everyone - tag PRs you want to land in 2.4.1, we'll try to get merged before next release Benedikt to check that modernization branch will work with 3.8 The meeting notes google doc is here <https://docs.google.com/document/d/1rJVU84B_dgx58-_EopjRtOJVFAI2WfHJYV0n7uE…>. Feel free to correct or add additional information. The next meeting will be held on Thursday, March 12th at 12pm EST, 9am PST, 6pm CET, 1am China. Mark Visser Tooling Dev Manager Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 3

How the clr module works with .NET imports
by adam.preble＠gmail.com 29 Apr '20

29 Apr '20

I'm curious about how the clr module and the subsequent imports work. I'm asking for a hand in understanding that since that's some pretty dense code for me to understand by myself. I'm doing this because I'm trying to have the same functions in my own pure .NET, async-await Python interpreter project. I have a fairly simple example I am using as a test that I got originally from IronPython--that also works with Python.NET: >>> import clr >>> clr.AddReference("System") <System.Reflection.RuntimeAssembly object at 0x0000022C20DA2438> >>> from System import Environment >>> Environment <class 'System.Environment'> Two questions: 1. Generally how does Python.NET track these references? I assumed there'd be a module loader for .NET DLLs but saw nothing in sys.meta_path. In my own project, I've been polluting the local context with a a __clr__ dunder. 2. How does Python.NET get Environment out of the System reference? Is it a misnomer? Environment's in mscorlib but the System namespace. I'm treating AddReference("System") as adding the System assembly, but I suppose it's more applicable to say it's adding the System namespace. I don't know how to represent that in .NET parlance. I found this, which seems rather tedious! https://stackoverflow.com/questions/79693/getting-all-types-in-a-namespace-… Presumably that would mean going through all references and finding matching namespaces.

1 0

Working group notes for April 23, 2020
by Victor “LOST” Milovanov 23 Apr '20

23 Apr '20

1 0

Working group notes for April 23, 2020
by Victor “LOST” Milovanov 23 Apr '20

23 Apr '20

1 0

Using Import method in C# Py.GIL
by murad.tulunay＠gmail.com 12 Apr '20

12 Apr '20

Hi, How can I write "from packet..messaging import MessagingClient" in Python.Runtime. I tried below code snipet "dynamic MessagingClient = Py.Import("packet.messaging");" Still heve exception:

1 0

TypeError for argument type IList <dynamic>
by gregor.hd＠gmx.de 11 Apr '20

11 Apr '20

Hi, I'm new to Python for .NET and to this mailing list. From the search results to my question I see I'm not the first person with my problem, yet the solution still evades me. When using the following function without AuxParameters everything works fine bool CalculateResult(string resultName, IntPtr resultArray, IList <dynamic> AuxParameters = null) but in cases where I do need a parameter I get a "TypeError: No method matches given arguments for CalculateResult". Any ideas how I can make this work? Here's what I tried: from System import Array, Int16 from System.Runtime.InteropServices import GCHandle, GCHandleType resultName = 'ABCD' result_index = 50 # set 0 if not needed! par = [result_index] a = [0] * 100 arr = Array[Int16](a) arr_hndl = GCHandle.Alloc(arr, GCHandleType.Pinned) ptr_arr = arr_hndl.AddrOfPinnedObject() if result_index: CalculateResult(resultName, ptr_arr, par) else: CalculateResult(resultName, arr) Thanks for any help, Greg

1 0

intermittent importerror unknown location, module imported as namespace, import from clr works
by Mark Mikofski 09 Apr '20

09 Apr '20

Sorry for starting a new thread if redundant. I have been a long time user of PythonNet and suddenly I am having an intermittent failure that I can't diagnose, PythonNet == 2.4.0.dev0 from pypi in Conda Python == 3.7.6 from conda main channel msvc 2019 I am using the following repository: https://github.com/mikofski/pv.net When I try to import pv.SolarPosition I get the following error: ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location) I've tried it a couple of ways: 1. add reference to assembly name, doesn't work >>> import clr >>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" >>> assy = clr.AddReference(assy_path) >>> import pv >>> pv <module 'pv' (namespace)> >>> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' >>> from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location) 2. add assembly path to PYTHONPATH or sys.path, neither works >>> import sys >>> assy_path = "C:\\Users\\mikm\\source\\repos\\pv.net\\bin" >>> sys.path.append(assy_path) >>> import clr >>> assy = clr.AddReference("pv") >>> import pv >>> pv <module 'pv' (namespace)> >>> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' >>> from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location) 3. import from clr, always works >>> import clr >>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" >>> assy = clr.AddReference(assy_path) >>> from clr import pv >>> pv <module 'pv' (namespace)> >>> pv.SolarPosition pv.SolarPosition >>> dates = ["19900101T12:30:00", "19900102T12:30:00", "19900103T12:30:00", "19900104T12:30:00"] >>> pv.SolarPosition(dates, 32.1, -121.0) 19900101T12:30:00 --> 1/1/1990 12:30 PM 19900102T12:30:00 --> 1/2/1990 12:30 PM 19900103T12:30:00 --> 1/3/1990 12:30 PM 19900104T12:30:00 --> 1/4/1990 12:30 PM 01/01/1990 12:30:00 --> 1.00 02/01/1990 12:30:00 --> 2.00 03/01/1990 12:30:00 --> 3.00 04/01/1990 12:30:00 --> 4.00 1.00 --> 0 2.00 --> 0.01721421 3.00 --> 0.03442841 4.00 --> 0.05164262 Out[35]: <pv.SolarPosition at 0x173cdd71c88> Even though I still can't import SolarPosition from pv at least call pv.SolarPosition. Weirdly, somehow if I import some other assemblies, which sometimes works, or if I keep trying long enough, suddenly it works, and I can import SolarPosition from pv using method 1 or 2. I don't know why, it's not repeatable. I recently made changes to my visual studio configuration, I only have build tools for 2015, visual studio 2017, and visual studio 2019. I am building using the makefile with visual studio 2019. I have tried compiling with either 2015 or 2017, but it doesn't seem to matter. I am using the native x64 environment. Also, maybe this matters, I started this project in visual studio 2019 as a .net core 3.1 project, and I noticed that it doesn't have AssemblyInfo.cs or a very big csproj file, but since I'm compiling from the command line using csc in the Makefile (see repo) I didn't think that would matter. Also, I tried an older project that I started using .Net Framework-4.5 and it also seems to work intermittently, inconsistently. My suspicion is that I somehow screwed up my .NET configuration, but not sure how or what. Anyway, if anyone has ever encountered this, or has any ideas, please let me know. I'm going a little crazy. thanks, Mark

4 3

Working group notes for April 9, 2020
by Victor “LOST” Milovanov 09 Apr '20

09 Apr '20

1 0