Mailman 3 - Python.NET

Mapped DataTypes of Python to .NET
by Satya Prasad 09 Jun '21

09 Jun '21

I have a 32 bit .NET DLL - so I made use of PythonNet Module <http://pythonnet.github.io/> and msl.loadlib.server32 module <https://msl-loadlib.readthedocs.io/en/latest/_api/msl.loadlib.server32.html> as I am using Python 64 bit version. I am a just a beginner in this domain - and below is my query. Thru ILSpy I can see the below signature: [DllImport("DISCOM.DLL", CharSet = CharSet.Unicode)] public static extern uint CancelRequests(IntPtr data); I tried opening DISCOM.DLL via ILSpy and Pythonnet but could not do so - how can we call the above API and create a Python datatype of IntPtr. Please let me know how to Convert Python data types to .NET format and vice versa Regards, Prakash

1 0

Working group notes for April 22, 2021
by Mark Visser 22 Apr '21

22 Apr '21

Attendees: Victor, Mark, Felix, Benoit Agenda: Review last week's action items: Victor to make a list of breaking changes in his branch that could land for 3.0 and discuss with Benedikt Felix to review #1426 <https://github.com/pythonnet/pythonnet/pull/1426> Victor to update Improve Python <-> .NET exception integration <https://github.com/pythonnet/pythonnet/pull/1134> Victor to update https://github.com/pythonnet/pythonnet/pull/1133 <https://github.com/pythonnet/pythonnet/pull/1133> and check with Benedikt that it's still good to land for 3.0 Benoit to test on Apple Silicon & derisk Notes: Improve Python <-> .NET exception integration <https://github.com/pythonnet/pythonnet/pull/1134> blocked: waiting for #1426 & #1441 to land Python 3.7 doesn't build on Apple Silicon fixes won't be backported to 3.7 3.9 is earliest version that will support Apple Silicon Action Items: Victor to make a list of breaking changes in his branch that could land for 3.0 and discuss with Benedikt Felix to review #1426 <https://github.com/pythonnet/pythonnet/pull/1426> & #1441 <https://github.com/pythonnet/pythonnet/pull/1441> Victor to update https://github.com/pythonnet/pythonnet/pull/1133 <https://github.com/pythonnet/pythonnet/pull/1133> and check with Benedikt that it's still good to land for 3.0 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, May 6 at 12pm EST (click for your time zone) <https://www.google.com/search?q=12:00+pm+EST>. Mark Visser Senior Dev Manager, M&E Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 0

Working group notes for April 8, 2021
by Mark Visser 08 Apr '21

08 Apr '21

Attendees: Victor, Mark, Felix, Benoit Agenda: Review last week's action items: everyone should look into the finalizer issues if they can PythonException finalizer update Notes: finalizer issues? not sure what this is referencing, Victor will talk to Benedikt PythonException finalizer update blocked due to failure on 3.6 Benedikt gave Felix pointers he needed to get unblocked Victor posted a pull that potentially fixes - this PR #1426 <https://github.com/pythonnet/pythonnet/pull/1426> Victor has a bunch of breaking changes he wants to potentially land for 3.0 feature: ability to add mix-ins to .NET types with Python solves multiple issues with dictionary conversions avoids having to create a proxy class in C# that doesn't behave like a C# dictionary allows you to create a class that works as a dictionary in both Python and C# fairly mature, possibly can land before 3.0 feature: change overload resolution to whatever dynamic does in C# solves problem where overloads behave in a surprising way barely a proof-of-concept (not even tested/validated/etc) feature: ability to change base class others Victor has many open PRs https://github.com/pythonnet/pythonnet/pulls/lostmsu <https://github.com/pythonnet/pythonnet/pulls/lostmsu> please review Have we tested on Apple Silicon no Benoit can test Travis? do we have automated testing on Mac? we do, AMD64 only we don't have a good debugger for 64-bit ARM Unity will need Apple Silicon support by November to make our Python package officially supported potentially lots of work Native code page still there? no, got removed Action Items: Victor to make a list of breaking changes in his branch that could land for 3.0 and discuss with Benedikt Felix to review #1426 <https://github.com/pythonnet/pythonnet/pull/1426> Victor to update Improve Python <-> .NET exception integration <https://github.com/pythonnet/pythonnet/pull/1134> Victor to update https://github.com/pythonnet/pythonnet/pull/1133 <https://github.com/pythonnet/pythonnet/pull/1133> and check with Benedikt that it's still good to land for 3.0 Benoit to test on Apple Silicon & derisk 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, April 22 at 12pm EST (click for your time zone) <https://www.google.com/search?q=12:00+pm+EST>. Mark Visser Senior Dev Manager, M&E Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 0

Python for Unity 4.0.0-exp.5 now available!
by Mark Visser 06 Apr '21

06 Apr '21

Hi everyone, I'm thrilled to announce that Python for Unity has been updated to support the latest Python for .NET! This update brings Python 3.7 support and the ability to use native Python modules. Well, technically you could use them before; the difference is that now Unity won't crash on domain reload if you do. :-) You can find more details in the official announcement <https://forum.unity.com/threads/python-for-unity-release-announcements.1084…>. I'm cross-posting here because this release would not have been possible without the joint efforts of Unity, Imaginary Spaces and the Python for .NET developers. Thank you Amos, Felix, Victor, Benedikt, and Benoit! cheers, -Mark Mark Visser Senior Dev Manager, M&E Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 0

Working group notes for March 25, 2021
by Mark Visser 25 Mar '21

25 Mar '21

Attendees: Benedikt, Mark Agenda: Review last week's action items: everyone should look into the finalizer issues if they can PythonException finalizer update Notes: No quorum, meeting canceled Action Items: Mark will check if dev work on existing Unity PRs is still in progress (if not, please comment on the PR when we expect work to resume) 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, April 8 at 12pm EST (click for your time zone) <https://www.google.com/search?q=12:00+pm+EST>. Mark Visser Senior Dev Manager, M&E Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 0

Working group notes for March 11, 2021
by Mark Visser 11 Mar '21

11 Mar '21

Attendees: Felix, Benoit, Mark Agenda: Review last week's action items: Amos will check if _GC_Calloc can be replaced with public function Felix will continue working on PythonException finalizer Notes: Benedikt agrees it's a good idea to get rid of _GC_Calloc, need to be mindful that allocation works with domain reload Technical discussion on debugging Current state of tests is that we have pytest and NUnit tests can run pytest through NUnit but not the inverse should we keep both? domain reload tests are separate (Re-enable the domain reload tests <https://github.com/pythonnet/pythonnet/pull/1404>) could trip up devs if they don't know to run the reload tests same situation right now with pytests & NUnit tests - need to run both locally document? make available via a single front-end? ideally running either pytest or NUnit tests runs all interesting tests most code is in C#, maybe dotnet test should run all tests, not pytest still nice to run pytest, allows us to write pytests in a meaningful way pytests are a bit hacky as they need to build the Python tests DLL ideal to run all tests through dotnet test - big project though create a bridge to run pytests via NUnit? Benedikt needs to think more on how to solve this current setup is fine for now (keep as separate steps) Modernize import hook <https://github.com/pythonnet/pythonnet/pull/1369> import hook as python code has implications can we embed it instead of having it as a .py file? Benedikt has no major changes planned going through PRs to get pythonnet into a stable state dealing with finalizer issues once main performance issues, finalizer fixes & import hook is merged we'll be ready for 3.0 the work Victor has started on reworking older components is good look at obsoleting unsafe interfaces before major release What does Unity need? import hook is the last thing we'd like to ship with an official 3.0 (currently shipping a git hash build) timeline for that is fall 2021 Action items: everyone should look into the finalizer issues if they can 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 25 at 12pm EST (click for your time zone) <https://www.google.com/search?q=12:00+pm+EST>. Mark Visser Senior Dev Manager, M&E Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 0

Working group notes for February 11
by Mark Visser 11 Feb '21

11 Feb '21

Attendees: Victor, Benedikt, Mark, Felix, Amos Agenda: Review last week's action items: Victor: fix merge conflict and merge PythonDLL PR Victor: create issue for domain reload when .NET objects point to PythonException and/or PyObject Benedikt will check if he can restore perf tests using wheel of 2.5.1 Notes: PythonDLL PR was merged domain reload when .NET objects point to PythonException and/or PyObject Felix found a problem, will create PR to fix PyValue wasn't reference counted PythonDLL work Python usually requires setting PYTHON_HOME - maybe we should try to discover DLL location from PYTHON_HOME instead of starting from the DLL location? PYTHON_HOME doesn't work very well for system environment maybe should try to discover PYTHON_HOME from DLL path instead? need to have both Benedikt will take a look at different OSes and see what could work CLR Loader PR The failures are due to Finalize call from Python on process shutdown, which previously was not there Calling Finalize is correct, but exposes preexisting bugs that now cause CI to fail can we ignore the CI failures and fix them as a separate issue? yes Benedikt will move code fixing reference counting (and other changes unrelated to Finalize) and enabling Finalize to a new branch and land CLR loader we'll treat the surfaced Finalize issues separately Felix will need to rebase his PR CI will continue to non-deterministically fail in the interim weakref support PR need to fix some bugs to pass CI Action items: Felix will create PR to likely fix Domain reload crashes when .NET object points to PythonException <https://github.com/pythonnet/pythonnet/issues/1371> Benedikt will look into automatically setting PYTHON_HOME and/or inferring location of Python DLL Benedikt will comment on the CLR Loader regarding Finalize call from Python on process shutdown and merge the PR 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, February 25 at 12pm EST (click for your time zone) <https://www.google.com/search?q=12:00+pm+EST>. Mark Visser Senior Dev Manager, M&E Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 0

Visual Studio extension to convert [DllImport] into new unmanaged function pointers
by Victor Milovanov 11 Feb '21

11 Feb '21

OneDrive link: https://1drv.ms/u/s!AioR7aFFo_FKzuwi_AkxqtZj7JnXhw?e=uriiwU This is a custom build of Roslynator You write something like [DllImport(PythonDLL, CallingConvention = CDecl)] public extern void PyProc(); Then VS should offer a refactoring, that converts this to unmanaged pointers. // Victor

1 0

Wrap in interface (#1240)
by Mohamed Koubaa 09 Feb '21

09 Feb '21

Hello, This PR<https://github.com/pythonnet/pythonnet/pull/1240> changed behavior of pythonnet to use stricter typing when a method returns an interface. I'd like a way to opt-out of this behavior, and I'll share a representative use-case below. The tl;dr is that python is a dynamic language and I expect the C# objects which pythonnet wraps to behave more like "dynamic" and less like the static types on the interface. **** C# code **** namespace Example1 { public enum ShapeType { Square, Circle } public interface IShape { void Draw(); double Area { get; } ShapeType Type { get; } } public class Square : IShape { public double Length { get; } public Square(double length) { Length = length; } public void Draw() {} public double Area { get { return Length * Length; } } public ShapeType Type { get { return ShapeType.Square; } } } public class Circle : IShape { public double Radius { get; } public Circle(double radius) { Radius = radius; } public void Draw() {} public double Area { get { return Math.PI * Radius * Radius; } } public ShapeType Type { get { return ShapeType.Circle; } } } public class ShapeDataModel { private Dictionary<int, IShape> _shapes = new Dictionary<int, IShape>(); private int _nextId = 1; public int AddShape(IShape shape) { int id = _nextId; _shapes[id] = shape; _nextId++; return id; } public IShape GetShape(int id) { return _shapes[id]; } } } **** Python code **** >>> import clr >>> clr.AddReference("Example1") >>> import Example1 >>> sq1 = Example1.Square(2.) >>> ci1 = Example1.Circle(1.3) >>> sq2 = Example1.Square(2.5) >>> m = Example1.ShapeDataModel() >>> m.AddShape(sq1) 1 >>> m.AddShape(sq2) 2 >>> m.AddShape(ci1) 3 >>> m.GetShape(2) <Example1.IShape object at 0x000002A3448A09A0> >>> m.GetShape(2).Area 6.25 >>> m.GetShape(2).Length Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'IShape' object has no attribute 'Length' **** summary **** This factory and/or datamodel pattern is very common in my codebase and probably also lots of object oriented systems. The mentioned PR breaks this common design pattern in C# objects wrapped by pythonnet, and I would like a way to opt-out of it. Maybe an attribute on the method which returns an interface can be used, or maybe something global to switch this behavior. I think perhaps the original bug might also have been fixed in a different way. Thanks! Mohamed

2 5

Binary file passed to .Net object
by Alexander Masis 28 Jan '21

28 Jan '21

Hello, guys here is a prototype code: exAsseblyRef = clr.AddReference("C:\ExamRecordHelper") from ExamRecordHelper import * loaderObj = ExamRecordLoader( 'MyBinaryFile.bin') <<<<<< Exception here. On the 3d line the C# constructor ExamRecordLoader(String) is called - it can't create the object. The actual exception is: "Column requires a valid DataType." However, the same binary file used with native C# code: ExamRecordLoader( 'MyBinaryFile.bin') works with no errors. Obviously something is happening when the binary file is being used by the C# class... Any suggestions? Thanks, Alex.

4 6