Mailman 3 February 2021 - Python.NET

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 08 Feb '21

08 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