[Python.NET] Working group notes for January 30, 2020

[Mark Visser]

Attendees: Benedikt, Victor, Amos, Benoit, Mark

Agenda
Review action items from last meeting:
Benedikt will continue working on .NET foundation application
Victor - will continue review of CLR loader PR
Benedikt - review codec PR please
Benoit - multithreaded python code
Victor - will work on breaking up Quantconnect PR 
Mohamed will rebase #974 on top of Victor's codec PR
? - github actions
Amos - will take changes made to PR #958 and push to #1016, address comments


Notes
Benoit looked at releasing threads on initialization return for multithreaded python code
use case is initializing Python.NET in Unity, on return GIL is held, workaround doesn't need Python.NET change (just release GIL from C#)
should the solution be in user code or Python.NET? discussion around tradeoff between complexity for users and correct behaviour
Could this be opt-in via e.g. attributes? So existing code continues to work without change.
Currently PyGIL attribute doesn't do anything, purely documentation
Current behaviour is somewhat surprising
First step is to document behaviour
Benedikt still working on .NET foundation application
seems to be in some triage stage, not rejected but not progressing either
will continue with personal membership and keep application moving
CLR loader
still WIP, can load any CLR into Python
dynamic loading of Python.NET is messy, 
problems around PInvoke and content string, works in Mono and .NET framework
should work in .NET core but first function call that hits Python function fails with missing DLL from the PInvoke call
we want PInvoke to call into symbols in the existing namespace so can use current Python exe (without Python so/dll)
very WIP
could this be split into multiple work items?
goal is to have a single deployment, but maybe this work can be split up
there are a lot of people asking for .NET core support, splitting would help that
Codec PR
target a specific version or just merge into master once it passes CI?
merge into new branch for next version?
or make functions internal and use [InternalsVisibleTo] in master?
just land in master
tuple converter looks more like an example of how code should be done - maybe move out of main assembly to an example project?
internal conversions should be rewritten using codec API
PR #1016
Amos merged changes to the PR
Some test failures need to be addressed
Linux 3.7 crash
not sure if errors are legitimate or test framework failure
seems to be infrastructure instability? Victor saw same crash on other branch
try again?
Is there a release schedule? not really
want to get Amos' big change into master before next release so we can update Python for Unity (sometime in 2020)
needs input from Benedikt

Action Items
Benoit will write github issue documenting GIL best practices when running multithreaded code and possible solutions
Benedikt will look into splitting up CLR loader into multiple work items to speed up .NET Core support
Victor will address comments on codec PR
Victor - will work on breaking up Quantconnect PR 
Mohamed will rebase #974 on top of Victor's codec PR
? - github actions
Victor will send Benoit & Felix build that failed on Linux 3.7
Benoit will continue working on PR #1016
Amos is having connection issues and will send an update email to the mailing 
list

The meeting notes google doc is here <https://docs.google.com/document/d/1rJVU84B_dgx58-_EopjRtOJVFAI2WfHJYV0n7uE1Oak/edit#>. Feel free to correct or add additional information.

The next meeting will be held on Thursday, February 13th at 12pm EST, 9am PST, 6pm CET, 1am China. 

Mark Visser
Tooling Dev Manager
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythondotnet/attachments/20200130/f785e55b/attachment-0001.html>