Mailman 3 January 2020 - Python.NET

Notes for #958 & #1016
by Li Amos Jan. 30, 2020

Jan. 30, 2020

For #958, I droped NativeCodePage dependency, it makes no need for writting the machine code to makes dummy slots at all. I was thinking is it possible to keep thouse clr moduel alive after domain reload. I may try to implement it if I could. Actually, it won't be easy to make #1016 pass all tests as an independency, since many pre conditions are not completed. Like some refcnt fixes it doesn't possess. For achieving the soft shutdown, I have to fixes some flaws and bugs whiches on master branch in #958. That making the PR become biger and biger(some are the optimizations I added passingly). Thouse bugs maybe insignificances(reference count error, memory leaks, etc.) on master branch, be they may be the criticals when you try to reset the python runtime, you have to wipe them out first. About those weird crashes in other branches, they're not the odd. since I fixed the bugs I found in my branch, I have great confidence that if you try to merge #958 into them, they may pass. So I still recommend merge #958 directly, split them just reduce efficiency, because I have to consider the merge order if I need all tests pass. But now the efficiency of merge progress is worse. #1016 may be the one very close the final one if it have to be split.

1 0

Working group notes for January 30, 2020
by Mark Visser Jan. 30, 2020

Jan. 30, 2020

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-_EopjRtOJVFAI2WfHJYV0n7uE…>. 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/>

1 0

Re: [Python.NET] Working group meeting notes for December 5, 2019 - CANCELLED
by Victor “LOST” Milovanov Jan. 16, 2020

Jan. 16, 2020

1 0

Working group notes for January 16, 2020
by Mark Visser Jan. 16, 2020

Jan. 16, 2020

Attendees: Felix, Mark, Victor, Mohamed, Amos Agenda Review action items from last meeting: 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 Victor - breaking up Quantconnect PR ? - github actions Benedikt - will try to reproduce PyBuffer crash locally Notes Victor took a look at CLR loader PR, review in progress Perf stats on hold as they aren't supported by Appveyor/Travis, would need an external server to record stats Codec PR published, needs review from Benedikt Mohamed will rebase #974 on top of Victor's codec PR PR #1016 - some bugs in this PR have been fixed in #958 by Amos Felix working through domain reload changes, updating to master and reviewing PR plan is to break up PR #958 General note: please participate in PR reviews and/or take a look at the PyBuffer crash. Action Items 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 ? - github actions Amos - will take changes made to PR #958 and push to #1016, address comments 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, January 30th at 12pm EST, 9am PST, 6pm CET, 1am China. Mark Visser Tooling Dev Manager Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 0

Working group meeting notes for December 5, 2019 - CANCELLED
by Mark Visser Jan. 16, 2020

Jan. 16, 2020

Attendees: Mohamed, Amos, 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 Notes Quorum not reached, meeting cancelled 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 19th at 12pm EST, 9am PST, 6pm CET, 1am China. Mark Visser Tooling Dev Manager Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

3 2

Support for Python 3.8
by Anand Mohan Jan. 13, 2020

Jan. 13, 2020

Hello - We are exploring Python 3.8 currently in our organization. I have used PythonNet in the past and I see it is supported until 3.7. Will support for Python 3.8 be available for PythonNet? Regards, Anand CONFIDENTIALITY NOTICE: This communication contains information intended for the use of the individuals to whom it is addressed and may contain information that is privileged, confidential or exempt from other disclosure under applicable law. If you are not the intended recipient, you are notified that any disclosure, printing, copying, distribution or use of the contents is prohibited. If you have received this in error, please notify the sender immediately by telephone or by returning it by return mail and then permanently delete the communication from your system. Thank you.

1 0

Will 2.4.0 be built for Python 3.8?
by Steven Rumbalski Jan. 2, 2020

Jan. 2, 2020

Hi, Will 2.4.0 be built for Python 3.8 or is the plan to wait for 2.4.1? Is there a time frame in mind for Python 3.8 support? Thank you, Steven Rumbalski

1 0