[Python.NET] Working group meeting notes for December 19, 2019

[Mark Visser]

Attendees: Benedikt, Victor, Amos, Mohamed, Mark

Agenda
Review action items from last meeting:
Benedikt - continue working on joining .NET foundation 
Benoit - multithreaded python code
? - breaking up Quantconnect PR 
? - github actions
Amos - continue breaking up pull 958 into smaller PRs to make it easier to review and merge.  e.g. have a single PR that gets reference counts right and doesn't touch GC chains. See Benoit's example of the __import__ restore PR for best practices.
Amos - same for other older PRs
Benedikt - will try to reproduce PyBuffer crash locally
Benedikt - will check if there are any breaking changes since 2.4.0
Benedikt - continue exploring CLR loader, splitting parts into separate Python interop DLLs, have main Python runtime implement layers on top
Victor - Perf runs in CI
Review PRs
Mailing list
currently moderated - @markv asked for ownership to be transferred to Benedikt

Notes
joining .NET
process had changed, Benedikt working on it
Pull 958 (domain reload handling)
split PRs being approved and merged, thanks Amos!
github actions
if we join .NET we can stay on current setup
would be nice to have Darwin CI working
PyBuffer
nothing done yet
CLR loader
modernization PR has a single build
Python 2 should still work, but Benedikt won't spend a lot of time on Python 2, 3.5+ is current focus
moved code and tests into separate directories
removed old csproj file in favour of small project files generated using .NET CLI
goal is a fully building project using .NET CLI that is operating system independent
made a small pythonnet module that will be the future entry point
still rough, testing currently with core CLR and Mono on Linux
loading works, P/Invoke __internal breaks on .NET core
Python functions have been split out into an interface
using T4 templates
ready for early review if you can take a look
Performance tests and CI
not very stable if we put in CI, fail depending on weather conditions
no way to put in CI without random failures
maybe makes sense to keep it as an ongoing statistic on master and not blocking PRs
useful for running locally on branch vs. master to check for regressions
still informative for detecting regressions - we can run it on every PR, but it shouldn't result in a hard error - can we report it on the PR?
perf comparison is relative, so different machines shouldn't affect the result
Mailing list
keep it, but remove moderation, transfer ownership to Benedikt
Improve method binding PR #974 discussion
Meeting on January 2 is cancelled, next meeting will be in 4 weeks on Thursday, January 16, 2020

Action Items
Benedikt will continue working on .NET foundation application
Victor will take a look at the CLR loader PR, looks big though
Victor will look into if we can generate perf stats through AppVeyor and Travis
Victor will publish a PR for conversion config
Mohamed will split PR #974
Benoit - multithreaded python code
? - breaking up Quantconnect PR 
Benedikt - will try to reproduce PyBuffer crash locally

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.

Please note there will be no meeting on January 2nd. The next meeting will be held on Thursday, January 16th at 12pm EST, 9am PST, 6pm CET, 1am China. 

Happy holidays!


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/20191219/47c5835c/attachment-0001.html>