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/>
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
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