Hello,
has anyone successfully used multithreading or multiprocessing with Python.Net?
I tried to multi-thread from the .Net side and the Python.Net libraries seem to have issues in the RunScript method. I had to take an implementation off the web of that method because the shipped method doesn’t seem to work.
I then had a working multi-processing example from CPython that I tried from Python.Net but it gives an error
'module' object has no attribute 'argv'
When trying to create a process pool by executing the line
pool = Pool(processes=4)
Is it possible to do multithreading or multiprocessing with Python.Net?
Thanks,
Alan
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
Hi,
I need your help regarding how to run Pythinon.net Demo samples (C:\Program Files\PythonNet\demo) in c#.
Best Regards,
Vishal Patel | PROJECT LEADER
Openxcell
Email Id: seo4(a)openxcelltechnolabs.com
Website: http://www.openxcell.com
Hello,
I work on a commercial Python package which I am currently enhancing to use Python.Net in order to access some .Net libraries.
Before using Python.Net we specified to end users that the requirement for running our package was "Python 3 installed". Now that we are using Python.Net we can't say that statement because Python.Net 2.5.1 supports Python 3.8 but not Python 3.9.
Since our package is not a stand-alone application, but it instead provides a Python API for users Python scripts to call, it's not an option for us to convert the whole delivery into an exe using something like PyInstaller.
So I'm looking for advice about the best option:
1. Specify that end users install a specific version of Python (3.8) in order to use our application.
2. Include Python 3.8 in our installer and install this if it's not already installed. Is this a good idea?
3. Any other ideas?
Many thanks,
DareDevilDenis
Attendees: Victor, Benedikt, Mark, Amos, Benoit, Felix
Agenda
Review last week's action items:
Felix & Benoit to add tests to master in preparation for the soft reload fix PR - will be ignored for now (or expected to fail - ideal if that's possible)
Victor to review these to understand the need for isolated testing environment for each test
discuss soft init/reload/shutdown modes: what are the use cases for each? are they all necessary? need to document if so. (Benoit/Felix)
Notes:
PR for soft reload tests is failing, hasn't run on travis
coverage reported is not accurate
let's not worry too much about the coverage numbers and try to provide good tests for new features
build times have gotten slower over time due to testing all shutdown modes
do we need to run full tests for all modes?
some of this is likely redundant
let's remove unnecessary tests from travis
additional run for every mode
github actions?
we should keep at least one version of python testing all shutdown modes
drop everything except 3.7 from testing shutdown since that's the version we support in Unity?
still want to catch regressions caused by new Python versions (e.g. API changes)
long term we should look at moving from travis to github actions
Unity shutdown/domain reload is using reload mode. do we need other two modes? (soft / none)
we never use reloading when embedding C# in Python - just kill workers/instances and restart
can we remove soft & none modes?
what are the use cases for the other two modes?
reload mode requires implementing a customer serializer
for CLR objects
Feilx is working on making the custom serializer optional so it still works without it
with this update reload won't fail without a serializer
does this make soft mode redundant?
there are a lot of places where there are three code paths depending on the shutdown mode - can we simplify
soft mode has no such requirement
none - used for shutting down Python and not restarting it - makes no attempt to save state
soft - does not maintain connections between CLR and Python objects, but saves state of Python interpreter
reload - also maintains connections between CLR and Python objects
all three modes are useful as they facilitate testing different parts of the system
e.g. if something fails on only one of the modes, it's useful data
currently all tests are run with all modes in all versions
Travis problems
jobs take forever to start
job status not reporting
at least partly connected to new free tier limitations
https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing <https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing>
we will need to move things off travis-ci.org by the end of the year
travis is shutting down free travis access due to abuse
move to travis-ci.com, still potential for free use but will be potentially limited
longer term move to github actions needs to be evaluated
Benedikt's SDK-style build system branch working well, except for some unexpected crashes
using poetry instead of setuptools - much simpler than current
PRs to come
Action items:
Felix will reduce the test combinations for soft shutdown on appveyor and travis to reduce build times and make a PR
Felix will look at extracting domain reload tests to reduce/simplify build times and report back
Benedikt will fix 32-bit issues
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, December 3 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/>
