from:"mark"

[Python.NET] How do you add an element to a List in a read-only property?

2020-03-03 Thread mark

Hello,

I think this is a really basic question, but I haven't found a solution.  I've 
been asked to use a .NET assembly from python.  I have programed in other 
languages, but not C#.  In the brief time I've used it, PythonNet has been 
fantastic... with one little wrinkle.  

Here's a pared down version of the C#:

namespace Service.API
{
public class ServiceAPI 
{
private static ServiceAPI m_Instance = new ServiceAPI();

public static ServiceAPI Instance
{
get
{
return m_Instance;
}
}

public ServiceAPI() 
{
}

~ServiceAPI() {}

ServiceInformation m_ServiceInformation = new ServiceInformation();

public List ServiceHosts
{
get
{
return m_ServiceInformation.ServiceHosts;
}
}
}

public class ServiceInformation 
{
public List ServiceHosts { get; set; }

public ServiceInformation()
{
ServiceHosts = new List();
}
}
}

I need to add strings to the List "ServiceHosts" in ServiceAPI.  The author 
placed the List inside another class, "ServiceInformation" and did not provide 
a set method, so that the ServiceHosts could not be altered to another object, 
while allowing strings to be added and removed from it.  

I think adding a string to that list is trivial in C#: (I've been assured by 
the assembly author that this works)
ServiceAPI.Instance.ServiceHosts.Add('1.1.1.1');

So I try it in Python:
>>> import clr  # Pyton.NET package
>>> clr.AddReference("Service.API") 
>>> import Service.API
>>> import System   # This is a .NET package.  
>>> Service.API.ServiceAPI.Instance.ServiceHosts.Add('1.1.1.1')
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'ServiceAPI' object has no attribute 'Add'

This is a List that PythonNet is mapping onto a python list:
>>> Service.API.ServiceAPI.Instance.ServiceHosts
[]

So try using a python method:
>>> Service.API.ServiceAPI.Instance.ServiceHosts.append('1.1.1.1')
>>> Service.API.ServiceAPI.Instance.ServiceHosts
[]

Nope.  And I start suspecting that I've added that string to a boxed version of 
the list.  But because there's no set accessor, I can't do this:
>>> hosts = Service.API.ServiceAPI.Instance.ServiceHosts
>>> hosts.append('1.1.1.1')
>>> Service.API.ServiceAPI.Instance.ServiceHosts = hosts
Traceback (most recent call last):
  File "", line 1, in 
TypeError: property is read-only

So what about calling the unbound list method, passing in the list?
>>> System.Collections.Generic.List[String].Add(
Service.API.ServiceAPI.Instance.ServiceHosts, '1.1.1.1')
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'ServiceAPI' object has no attribute 'Add'

The author of this assembly has offered to create a specific method so that I 
can access the list, but he assures me that this is a common C# pattern that I 
will encounter frequently.  

I can't just create an instance of ServiceInformation and add the hosts to 
that, ServiceAPI has no method for getting or setting m_ServiceInformation.  

Any help in setting me in the right direction would be appreciated.

Thanks,

Mark Brighton
___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/

[Python.NET] Re: Accessing a list that is a read-only property?

2020-03-04 Thread mark

Victor,

Thank you for the help.  I can see in that issue, fartsmajeure gave pretty much 
the same example on June 5, 2019.  I'll have a method added to work around it.  

Cheers,
Mark
___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/

[Python.NET] Accessing a list that is a read-only property?

2020-03-03 Thread Mark Brighton

Hello,

I think this is a really basic question, but despite searching I haven't found 
a solution.  I've been asked to use a .NET assembly from python.  I have 
programed in other languages, but not C#.  In the brief time I've used it, 
PythonNet has been fantastic... with one little wrinkle.  

Here's a pared down version of the C# that I’m trying to access from Python:

namespace Service.API
{
public class ServiceAPI 
{
private static ServiceAPI m_Instance = new ServiceAPI();

public static ServiceAPI Instance
{
get
{
return m_Instance;
}
}

public ServiceAPI() 
{
}

~ServiceAPI() {}

ServiceInformation m_ServiceInformation = new ServiceInformation();

public List ServiceHosts
{
get
{
return m_ServiceInformation.ServiceHosts;
}
}
}

public class ServiceInformation 
{
public List ServiceHosts { get; set; }

public ServiceInformation()
{
ServiceHosts = new List();
}
}
}

I need to add strings to the List “ServiceHosts”, accessing it via a ServiceAPI 
object.  The author placed the List inside another class, "ServiceInformation" 
and did not provide a set accessor, so that the ServiceHosts could not be 
altered to another object, while allowing strings to be added and removed from 
it.  

I think adding a string to that list is trivial in C#: 
ServiceAPI.Instance.ServiceHosts.Add('1.1.1.1');

So I try it in Python:
>>> import clr  # Pyton.NET package
>>> clr.AddReference("Service.API") 
>>> import Service.API
>>> import System
>>> Service.API.ServiceAPI.Instance.ServiceHosts.Add('1.1.1.1')
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'ServiceAPI' object has no attribute 'Add'

This is a List that PythonNet is mapping onto a python list:
>>> Service.API.ServiceAPI.Instance.ServiceHosts
[]

So try using a python method:
>>> Service.API.ServiceAPI.Instance.ServiceHosts.append('1.1.1.1')
>>> Service.API.ServiceAPI.Instance.ServiceHosts
[]

Nope.  And I start suspecting that I've added that string to a boxed version of 
the list.  But because there's no set accessor, I can't do this:
>>> hosts = Service.API.ServiceAPI.Instance.ServiceHosts
>>> hosts.append('1.1.1.1')
>>> Service.API.ServiceAPI.Instance.ServiceHosts = hosts
Traceback (most recent call last):
  File "", line 1, in 
TypeError: property is read-only

So what about calling the unbound list method, passing in the list?
>>> System.Collections.Generic.List[String].Add(
Service.API.ServiceAPI.Instance.ServiceHosts, '1.1.1.1')
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'ServiceAPI' object has no attribute 'Add'

The author of this assembly has offered to create a specific method so that I 
can access the list, but he assures me that this is a common C# pattern that I 
will encounter frequently.  

I can't just create an instance of ServiceInformation and add the hosts to 
that, ServiceAPI has no method for getting or setting m_ServiceInformation.  

Any help in setting me in the right direction would be appreciated.

Thanks,

Mark Brighton
___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/

[Python.NET] Working group notes for March 26, 2020

2020-03-27 Thread Mark Visser

Attendees: Victor, Benedikt, Amos, Mohamed, Mark

Agenda
Review action items from last meeting:
[x] Mohamed will work on list and action codec PRs
[x] Victor will ask Benedikt about older solution files/create an issue
[x] Victor will look again at Mohamed’s issue with VS 2019
[ ] Continue PyHandle/References discussion on GitHub
[x] Victor will start a discussion about serializing user objects - it might be 
highly misleading
[ ] Amos will create a test for WrapperStorer demonstrating it
release plan?

Notes
List & action codec PRs
working through comments
will put function codec into codec repo
older solution files
everything has not been converted to new project format
old solution files still used by one of the appveyor builds
Mono build uses xbuild? 
we should use .NET CLI for building
what if users only have mono?
building by yourself is painful
older solutions should be removed
Benedikt has removed it in a branch
serializing user objects
discussion will continue in PR
private mailing list has been created
contact Benedikt/Victor if you want to be on the mailing list
use this for any future security issues / contacts
joining .NET foundation
got a new questionnaire, upcoming boarding meeting discussing new applications
please review PR #1094 on finalize that Victor created
what's going in the next release?
finalizing Python 3.x support should go in
memory dump can go in
nested namespaces? 
Benedikt: deprecation warning about implicit loading is wrong and we should 
remove it
codec groups?
re: IronPython compatibility
 import system vs. import clr
current system replaces __import__ and is overly invasive

Action Items
[ ] Viktor to create issue to track removing old solutions
[ ] Continue PyHandle/References discussion on GitHub
[ ] Amos will create a test for WrapperStorer demonstrating it
[ ] Amos please review PR #1094
[ ] Benedikt will review codec groups PR

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, April 10 at 12pm EST, 9am PST, 6pm 
CET, 1am China.


Mark Visser
Tooling Dev Manager
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>




___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/

[Python.NET] intermittent importerror unknown location, module imported as namespace, import from clr works

2020-04-09 Thread Mark Mikofski

Sorry for starting a new thread if redundant. I have been a long time user of 
PythonNet and suddenly I am having an intermittent failure that I can't 
diagnose,

PythonNet == 2.4.0.dev0 from pypi in Conda
Python == 3.7.6 from conda main channel
msvc 2019

I am using the following repository:
https://github.com/mikofski/pv.net

When I try to import pv.SolarPosition I get the following error:

ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)

I've tried it a couple of ways:

1. add reference to assembly name, doesn't work
>>> import clr
>>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll"
>>> assy = clr.AddReference(assy_path)
>>> import pv
>>> pv

>>> pv.SolarPosition
AttributeError: module 'pv' has no attribute 'SolarPosition'
>>> from pv import SolarPosition
ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)

2. add assembly path to PYTHONPATH or sys.path, neither works
>>> import sys
>>> assy_path = "C:\\Users\\mikm\\source\\repos\\pv.net\\bin"
>>> sys.path.append(assy_path)
>>> import clr
>>> assy = clr.AddReference("pv")
>>> import pv
>>> pv

>>> pv.SolarPosition
AttributeError: module 'pv' has no attribute 'SolarPosition'
>>> from pv import SolarPosition
ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)


3. import from clr, always works
>>> import clr
>>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll"
>>> assy = clr.AddReference(assy_path)
>>> from clr import pv
>>> pv

>>> pv.SolarPosition
pv.SolarPosition
>>> dates = ["19900101T12:30:00", "19900102T12:30:00", "19900103T12:30:00", 
>>> "19900104T12:30:00"]
>>> pv.SolarPosition(dates, 32.1, -121.0)
19900101T12:30:00 --> 1/1/1990 12:30 PM
19900102T12:30:00 --> 1/2/1990 12:30 PM
19900103T12:30:00 --> 1/3/1990 12:30 PM
19900104T12:30:00 --> 1/4/1990 12:30 PM
01/01/1990 12:30:00 --> 1.00
02/01/1990 12:30:00 --> 2.00
03/01/1990 12:30:00 --> 3.00
04/01/1990 12:30:00 --> 4.00
1.00 --> 0
2.00 --> 0.01721421
3.00 --> 0.03442841
4.00 --> 0.05164262
Out[35]: 

Even though I still can't import SolarPosition from pv at least call 
pv.SolarPosition.

Weirdly, somehow if I import some other assemblies, which sometimes works, or 
if I keep trying long enough, suddenly it works, and I can import SolarPosition 
from pv using method 1 or 2. I don't know why, it's not repeatable.

I recently made changes to my visual studio configuration, I only have build 
tools for 2015, visual studio 2017, and visual studio 2019. I am building using 
the makefile with visual studio 2019. I have tried compiling with either 2015 
or 2017, but it doesn't seem to matter. I am using the native x64 environment.

Also, maybe this matters, I started this project in visual studio 2019 as a 
.net core 3.1 project, and I noticed that it doesn't have AssemblyInfo.cs  or a 
very big csproj file, but since I'm compiling from the command line using csc 
in the Makefile (see repo) I didn't think that would matter.

Also, I tried an older project that I started using .Net Framework-4.5 and it 
also seems to work intermittently, inconsistently. My suspicion is that I 
somehow screwed up my .NET configuration, but not sure how or what.

Anyway, if anyone has ever encountered this, or has any ideas, please let me 
know. I'm going a little crazy.

thanks,
Mark
___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/

[Python.NET] Re: intermittent importerror unknown location, module imported as namespace, import from clr works

2020-04-09 Thread Mark Mikofski

Thank but it doesn't seem to work consistently. It worked the first time I
compiled it, but then wouldn't work again, similar to the behavior I was
already seeing. I don't think adding the other frameworks to
 had any effect in this particular situation, b/c I am
compiling from the x64 native tools command prompt for vs2019 using csc.exe
so I think I'm using the default .NET framework, but I don't know for sure.
If I check where csc I can see it's calling from
"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\MSBuild\Current\Bin\Roslyn\csc.exe"

If I add net45, net46, or net461 or any combination to the project, when I
load the solution, it doesn't reference dotnet core anymore, or any
framework. So any symbol from System is unreferenced. Maybe I need to add
the reference to other frameworks from the project inside Visual Studio.

Anyway, for the meantime this workaround seems to work:
```
from clr import pv
```
so I guess I'll have to do that or do as you did and just switch the
project to a .NET Framework.

thanks!

On Thu, Apr 9, 2020 at 4:17 PM Emmanuel Rutovic  wrote:

> Hi Mark,
>
> My understanding (and I might be wrong) is Pythonnet (Official Compiled
> Master branch) is *not* compatible with .Net Core and is compatible only
> with the .Net framework. Is it possible that you accidentally load .Net
> Framework libraries when you think they are .Net Core ?
> I spent a lot of time with a similar problem and I finally decided to
> compile my project also for .Net framework :
>
> .csproj:
>
>   
> netcoreapp3.1;net472
>   
>
> There are forks that are supposed to be compatible with .Net Core but I
> wasn't able to make them work either.
>
> I hope it helps,
> Emmanuel.
>
>
> On Thu, Apr 9, 2020 at 12:46 PM Mark Mikofski 
> wrote:
>
>> Sorry for starting a new thread if redundant. I have been a long time
>> user of PythonNet and suddenly I am having an intermittent failure that I
>> can't diagnose,
>>
>> PythonNet == 2.4.0.dev0 from pypi in Conda
>> Python == 3.7.6 from conda main channel
>> msvc 2019
>>
>> I am using the following repository:
>> https://github.com/mikofski/pv.net
>>
>> When I try to import pv.SolarPosition I get the following error:
>>
>> ImportError: cannot import name 'SolarPosition' from 'pv' (unknown
>> location)
>>
>> I've tried it a couple of ways:
>>
>> 1. add reference to assembly name, doesn't work
>> >>> import clr
>> >>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll"
>> >>> assy = clr.AddReference(assy_path)
>> >>> import pv
>> >>> pv
>> 
>> >>> pv.SolarPosition
>> AttributeError: module 'pv' has no attribute 'SolarPosition'
>> >>> from pv import SolarPosition
>> ImportError: cannot import name 'SolarPosition' from 'pv' (unknown
>> location)
>>
>> 2. add assembly path to PYTHONPATH or sys.path, neither works
>> >>> import sys
>> >>> assy_path = "C:\\Users\\mikm\\source\\repos\\pv.net\\bin"
>> >>> sys.path.append(assy_path)
>> >>> import clr
>> >>> assy = clr.AddReference("pv")
>> >>> import pv
>> >>> pv
>> 
>> >>> pv.SolarPosition
>> AttributeError: module 'pv' has no attribute 'SolarPosition'
>> >>> from pv import SolarPosition
>> ImportError: cannot import name 'SolarPosition' from 'pv' (unknown
>> location)
>>
>>
>> 3. import from clr, always works
>> >>> import clr
>> >>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll"
>> >>> assy = clr.AddReference(assy_path)
>> >>> from clr import pv
>> >>> pv
>> 
>> >>> pv.SolarPosition
>> pv.SolarPosition
>> >>> dates = ["19900101T12:30:00", "19900102T12:30:00",
>> "19900103T12:30:00", "19900104T12:30:00"]
>> >>> pv.SolarPosition(dates, 32.1, -121.0)
>> 19900101T12:30:00 --> 1/1/1990 12:30 PM
>> 19900102T12:30:00 --> 1/2/1990 12:30 PM
>> 19900103T12:30:00 --> 1/3/1990 12:30 PM
>> 19900104T12:30:00 --> 1/4/1990 12:30 PM
>> 01/01/1990 12:30:00 --> 1.00
>> 02/01/1990 12:30:00 --> 2.00
>> 03/01/1990 12:30:00 --> 3.00
>> 04/01/1990 12:30:00 --> 4.00
>> 1.00 --> 0
>> 2.00 --> 0.01721421
>> 3.00 -->

[Python.NET] Working group notes for May 7, 2020

2020-05-07 Thread Mark Visser

Attendees: Victor, Amos, Mark

Agenda
Review action items from last meeting
Victor: clean 2.x milestones
Benedikt/Mohamed: extract “Moving files around” PR
Benedikt/Mohamed: extract “Support for dotnet SDK” PR
Add new items to 2.x milestones. If no new items are added, we start cutting 
release after the first May meeting.
Amos: take a look at Finalizer PR: either resolve comments, or reply; 
accept/decline

Notes
clean 2.x milestones done, one task left waiting for Amos' review
Benedikt will try to find time to finish 3.8 support s.t. we can cut the 
release.
Unity working on packaging Python 3.8 + Python.NET for Unity package manager
will not be discoverable for everyone, but anyone will be able to access it by 
editing their package manifest
there will be a Unity forum announcement sometime in June

Action Items
Amos to review PR 1094
Benedikt/Mohamed: extract “Moving files around” PR
Benedikt/Mohamed: extract “Support for dotnet SDK” PR

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, May 21th at 12pm EST, 9am PST, 6pm 
CET, 1am China.

Mark Visser
M&E Dev Manager
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>



___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Re: Working group notes for May 7, 2020

2020-05-21 Thread Mark Visser

FYI, I had to regenerate the Zoom link: 
https://unity3d.zoom.us/j/96545674848?pwd=REc5bTVYSGt0UTdMdXRIRFVXMTlHdz09 
<https://unity3d.zoom.us/j/96545674848?pwd=REc5bTVYSGt0UTdMdXRIRFVXMTlHdz09>


> On May 7, 2020, at 12:22 PM, Mark Visser  wrote:
> 
> Attendees: Victor, Amos, Mark
> 
> Agenda
> Review action items from last meeting
> Victor: clean 2.x milestones
> Benedikt/Mohamed: extract “Moving files around” PR
> Benedikt/Mohamed: extract “Support for dotnet SDK” PR
> Add new items to 2.x milestones. If no new items are added, we start cutting 
> release after the first May meeting.
> Amos: take a look at Finalizer PR: either resolve comments, or reply; 
> accept/decline
> 
> Notes
> clean 2.x milestones done, one task left waiting for Amos' review
> Benedikt will try to find time to finish 3.8 support s.t. we can cut the 
> release.
> Unity working on packaging Python 3.8 + Python.NET <http://python.net/> for 
> Unity package manager
> will not be discoverable for everyone, but anyone will be able to access it 
> by editing their package manifest
> there will be a Unity forum announcement sometime in June
> 
> Action Items
> Amos to review PR 1094
> Benedikt/Mohamed: extract “Moving files around” PR
> Benedikt/Mohamed: extract “Support for dotnet SDK” PR
> 
> 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, May 21th at 12pm EST, 9am PST, 6pm 
> CET, 1am China.
> 
> Mark Visser
> M&E Dev Manager
> Unity Technologies - www.unity3d.com <http://www.unity3d.com/>
> 
> 
> 

___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for May 21, 2020

2020-05-21 Thread Mark Visser

Attendees: Victor, Amos, Mark

Agenda
Review action items from last meeting
Amos to review PR 1094
Benedikt/Mohamed: extract “Moving files around” PR
Benedikt/Mohamed: extract “Support for dotnet SDK” PR

Notes
Benedikt has been preparing for a release of 2.5
basically ready
Python 3.8 support has landed
updating change log and pip packages left to do
PR #1094 has landed
no progress on other two PRs

Action Items
Benedikt/Mohamed: extract “Moving files around” PR
Benedikt/Mohamed: extract “Support for dotnet SDK” PR

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, June 4th at 12pm EST, 9am PST, 6pm 
CET, 1am China.

Mark Visser
M&E Dev Manager
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>





___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for June 4, 2020

2020-06-04 Thread Mark Visser

Attendees: Benedikt, Victor, Mark

Agenda
Review action items from last meeting
Benedikt/Mohamed: extract “Moving files around” PR
Benedikt/Mohamed: extract “Support for dotnet SDK” PR

Notes
 PR 1094 reviewed by Amos (thanks!)
2.5 release in progress
PR 824 will go into 2.5
RC will be released this week - taking a while due to combination of platforms 
& python versions
github master branch will be 2.5 release and only land bug fixes
will only publish 2.5 to PyPI - not Nuget
Benedikt will start new develop branch after next meeting (June 18th)
once that's done we'll start integrating big PRs that break things (including 
dropping Python 2.x)
other PRs on hold until after 2.5 release
Victor's branch (for after 2.5 release)
worked on providing Python interfaces to existing .NET collections
implemented and injected mixins for stuff from collections.abc into reflected 
classes implementing interfaces from System.Collections.Generic
also implemented buffer interface for arrays
depends on features that haven't yet landed upstream
Python for .NET now part of the .NET foundation!
no change to the license
after the 2.5 release we can improve our appveyer setup


Action Items
Benedikt/Mohamed: extract “Moving files around” PR
Benedikt/Mohamed: extract “Support for dotnet SDK” PR

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, June 18th at 12pm EST, 9am PST, 6pm 
CET, 1am China.


Mark Visser
M&E Dev Manager
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>





___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for July 16, 2020

2020-07-16 Thread Mark Visser

Attendees: Benedikt, Mark, Amos

Agenda
Review action items from last meeting
Amos will try to fix soft shutdown 3.8 CI
Victor will try to reproduce soft shutdown 3.8 CI failure
Since the failure appears to be in codecs tests, Victor will try to check if 
any codecs fixes were not backported from Lost Tech branch


Notes
Soft shutdown - 
CI failure related to issue #891 
<https://github.com/pythonnet/pythonnet/issues/891> see 
https://github.com/pythonnet/pythonnet/blob/master/src/runtime/runtime.cs#L311 
<https://github.com/pythonnet/pythonnet/blob/master/src/runtime/runtime.cs#L311>
 
soft mode finished from Amos's side
still need test cases for reload mode - may have stability issues
Benedikt still reviewing
hold off merging until we're sure it's stable
Unity will do additional QA (use branch updated to master first)
Still some polish to be done
Some parts have already been merged to master via other PRs
small PR #1175 - Remove unnecessary `CheckExceptionOccurred` calls 
<https://github.com/pythonnet/pythonnet/pull/1175> 
looks good
comments from Victor to address
quantconnect branches 
will close

Action Items
Benedikt - Check whether we need to change the `WITH_DEBUG` variant of 
PyObject_TYPE for newer versions of Python (> 3.8?)
Benedikt - Add reference to backports-2.5 branch in README
Benedikt - Switch to .NET Standard for everything but ClrModule
Benedikt - Change project files to new format
Victor - Consider adding a StolenReference type
Benedikt - will look at Amos's fix for #891 issue in PR #958
Benedikt - will look into Python Buffer branch again

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, July 30 at 12pm EST (click for your 
time zone) <https://www.google.com/search?q=12:00+pm+EST>.


Mark Visser
M&E Dev Manager
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>





___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

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

2020-07-30 Thread Mark Visser

Attendees: Amos, Victor, Mark, Benedikt, Mohamed

Agenda
Review action items from last meeting
Benedikt - Check whether we need to change the `WITH_DEBUG` variant of 
PyObject_TYPE for newer versions of Python (> 3.8?)
Benedikt - Add reference to backports-2.5 branch in README
Benedikt - Switch to .NET Standard for everything but ClrModule
Benedikt - Change project files to new format
Victor - Consider adding a StolenReference type
Benedikt - will look at Amos's fix for #891 issue in PR #958
Benedikt - will look into Python Buffer branch again
Soft shutdown PR

Notes
Check whether we need to change the `WITH_DEBUG` variant of PyObject_TYPE for 
newer versions of Python (> 3.8?)
in newer versions of Python WITH_DEBUG builds have the same layout
we need to remove the special case
not high priority right now since it's 3.9+
Switch to .NET Standard for everything but ClrModule
Benedikt will complete today to unblock Mohamed
Change project files to new format
need to get rid of old project files and replace by new ones
CLR module needs to stay on old format
StolenReference type
created issue for StolenReference type 
<https://github.com/pythonnet/pythonnet/issues/1193>
Python Buffer branch again
up for grabs if someone else wants to contribute
is working fine - was held back until release because it's a Python 3-only 
branch
should be ready to be merged once rebased
Soft shutdown PR
Unity will test before fall
Python 3.9
multiphase initialization for modules
used for subinterpreter support among other things
every module is an object instead of a singleton
can have multiple instances of a module
thus there can be multiple instances of the clr module
can be opted out of - see PEP 489 <https://www.python.org/dev/peps/pep-0489/> 
(other PEPs are based on it as well)
may incur work on Python.NET side to support or disable
PEP 554 <https://www.python.org/dev/peps/pep-0554/> also relevant 
(subinterpreters python API for 3.10)
interesting for embedding use case of embedding Python into .NET
nicer API
seems like a good idea to leverage this for our own embedding API
needs investigation
Discussion on broken appveyor.yml fixed in PR #1175 
<https://github.com/pythonnet/pythonnet/pull/1175>
Action Items
Benedikt to confirm WITH_DEBUG builds need to be updated for 3.9 (low priority) 
and will create issue to document for later
Benedikt - Add reference to backports-2.5 branch in README
Benedikt - Switch to .NET Standard for everything but ClrModule
Benedikt - will look at Amos's fix for #891 issue in PR #958
Benedikt - will look into Python Buffer branch again
Benedikt to look into weirdness with pycparser in appveyor.yml (see PR #1175 
<https://github.com/pythonnet/pythonnet/pull/1175>)

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, August 13 at 12pm EST (click for 
your time zone) <https://www.google.com/search?q=12:00+pm+EST>.

Mark Visser
M&E Dev Manager
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>





___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for August 13, 2020

2020-08-13 Thread Mark Visser

Attendees: Mark, Benoit, Felix, Mohamed, Victor, Amos

Agenda
Review action items from last meeting:
Benedikt to confirm WITH_DEBUG builds need to be updated for 3.9 (low priority) 
and will create issue to document for later
Benedikt - Add reference to backports-2.5 branch in README
Benedikt - Switch to .NET Standard for everything but ClrModule
Benedikt - will look at Amos's fix for #891 issue in PR #958
Benedikt - will look into Python Buffer branch again
Benedikt to look into weirdness with pycparser in appveyor.yml (see PR #1175 
<https://github.com/pythonnet/pythonnet/pull/1175>)
Domain reload update

Notes
Felix has been testing domain reload branch
mostly success with a few fixes needed
issues 
if you register a Python function as a delegate directly into a C# event, it is 
not retained - currently throws an exception due to leaving the Python function 
in a bad state
would be ideal to bring back the connection
Acceptable to lose the connection, but must leave python.net in a good state 
otherwise
if you maintain a proxy to a C# object in Python, on domain reload the proxy 
usually gives several different exceptions and sometimes crashes
correct behaviour is to raise an exception, ideally the same one with no crashes
if an assembly/type/class member/etc is missing after domain reload, causes 
problems on the Python side
needs to be gracefully handled
finalizers at exit fix done by Felix
PR not yet made
other than these issues reload mode works really well
soft shutdown mode doesn't work well for domain reload
it unloads all modules, which doesn't work for native modules (by design)
intended for use in the game, not the editor
Victor approved landing it to master once remaining issues raised in PR are 
fixed
Felix/Benoit to fix the minor issues in the PR and land the patch
If it can't land to master, Victor will create a branch for it in the repo
Remaining issues found by Felix can land to master after the main PR lands to 
master. Process:
Fixes: Felix submits a PR for the fix (ideally with test case)
Issues: create an issue, Felix submits PR with test case, invites Amos to fix. 
Amos fixes it. Land PR with test case + fix to master.
Documentation would be good
Proposal: 
Unity/imaginary spaces writes an outline, 
amos fills in outline, 
Unity/imaginary spaces revises it
Python 2 support for soft shutdown / reload is not necessary.

Action Items
Benedikt to confirm WITH_DEBUG builds need to be updated for 3.9 (low priority) 
and will create issue to document for later
Benedikt - Add reference to backports-2.5 branch in README
Benedikt - Switch to .NET Standard for everything but ClrModule
Benedikt - will look at Amos's fix for #891 issue in PR #958
Benedikt - will look into Python Buffer branch again
Benedikt to look into weirdness with pycparser in appveyor.yml (see PR #1175 
<https://github.com/pythonnet/pythonnet/pull/1175>)
Felix to create test case for Amos that demonstrates the "Python function as 
delegate fails on reload" (and others) and log issue - will create unit tests 
to land after main PR lands
Benoit/Felix to create doc outline for reload & soft shutdown modes (developer 
docs)
Felix will fix remaining domain reload issues raised by Victor
Amos will fix new issues to land after main PR lands

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, August 27 at 12pm EST (click for 
your time zone) <https://www.google.com/search?q=12:00+pm+EST>.

Mark Visser
M&E Dev Manager
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>





___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for November 5, 2020

2020-11-19 Thread Mark Visser

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-_EopjRtOJVFAI2WfHJYV0n7uE1Oak/edit#>.
 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/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for January 14, 2021

2021-01-14 Thread Mark Visser

(I think I forgot to send out the previous meeting notes - you can find them in 
the Google doc linked at the bottom of this message)

Attendees: Benedikt, Mark, Victor, Benoit, Felix, Amos

Agenda
Review last week's action items:
Benedikt will fix 32-bit issues
Benedikt to add test that loads unicode function names
Felix will submit PR for #1333 (function delegates)
Felix will submit PR that rewrites import hook to use pure Python (see #1096 & 
#727)

Notes:
32-bit issues
nothing done yet, Benedikt will look into this
test that loads unicode function names
merged! PR #1329
problem was that we need to make sure we always use our own UTF-8 marshaller
we can't use the .NET one because it doesn't exist in all .NET frameworks
PR fixes the issue where Benedikt saw it, but there are possibly other places 
where the same issue exists
follow-up issue is #1354
let's link all encoding problems to this issue
in Python 3 it's all UTF-8
this particular issue (unicode function names) is fixed
function delegates 
merged! PR #1333
rewrite of import hook to use pure Python (see #1096 & #727)
in progress (Felix)
rewrite avoids entering C# unless we absolutely need to, because there's no way 
to prevent C# from "owning" a thread that calls C#, and once C# owns it domain 
reload hangs waiting for the thread to exit
fixes a common pattern "try import PySide; except: import PySide2" - previous 
implementation hits C# on the first import call, even if PySide doesn't exist
internal compiler error (https://github.com/dotnet/roslyn/issues/49760)
still present in latest .NET 5.0.2
might still be a Roslyn point release?
doesn't help because Roslyn likely frozen until .NET 6
Victor will find out when they plan on releasing a fix
required for replacing PInvoke delegates for reference types with using 
unmanaged function pointers (supposed to work in new C#, but triggers an 
internal compiler error)
blocking our ability to do a multi-stage startup and dynamically bind to the 
right Python dll/dso/dylib anywhere but Mono (which supports __Internal as the 
DllImport string)
helpful for embedding .NET in Python since want to use the statically linked 
symbols in the python executable - using a dynamic library, even if present, 
leads to weird problems
we'll find out if a fix is forthcoming and if not, use a workaround

Action items:
Benedikt will fix 32-bit issues
Felix will complete rewrite of import hook to avoid calling C# unless necessary
Victor will find out if there will be a Roslyn release fixing the internal 
compiler error

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, January 28 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/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for February 11

2021-02-11 Thread Mark Visser

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-_EopjRtOJVFAI2WfHJYV0n7uE1Oak/edit#>.
 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/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for March 11, 2021

2021-03-11 Thread Mark Visser

Attendees: Felix, Benoit, Mark
Agenda:
Review last week's action items:
Amos will check if _GC_Calloc can be replaced with public function
Felix will continue working on PythonException finalizer
Notes:
Benedikt agrees it's a good idea to get rid of _GC_Calloc, need to be mindful 
that allocation works with domain reload
Technical discussion on debugging
Current state of tests is that we have pytest and NUnit tests
can run pytest through NUnit but not the inverse
should we keep both?
domain reload tests are separate (Re-enable the domain reload tests 
<https://github.com/pythonnet/pythonnet/pull/1404>)
could trip up devs if they don't know to run the reload tests
same situation right now with pytests & NUnit tests - need to run both locally
document? make available via a single front-end?
ideally running either pytest or NUnit tests runs all interesting tests
most code is in C#, maybe dotnet test should run all tests, not pytest
still nice to run pytest, allows us to write pytests in a meaningful way
pytests are a bit hacky as they need to build the Python tests DLL 
ideal to run all tests through dotnet test - big project though
create a bridge to run pytests via NUnit?
Benedikt needs to think more on how to solve this
current setup is fine for now (keep as separate steps)
Modernize import hook <https://github.com/pythonnet/pythonnet/pull/1369>
import hook as python code has implications
can we embed it instead of having it as a .py file?
Benedikt has no major changes planned
going through PRs to get pythonnet into a stable state
dealing with finalizer issues
once main performance issues, finalizer fixes & import hook is merged we'll be 
ready for 3.0
the work Victor has started on reworking older components is good
look at obsoleting unsafe interfaces before major release
What does Unity need?
import hook is the last thing
we'd like to ship with an official 3.0 (currently shipping a git hash build)
timeline for that is fall 2021

Action items:
everyone should look into the finalizer issues if they can

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






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for March 25, 2021

2021-03-25 Thread Mark Visser

Attendees: Benedikt, Mark
Agenda:
Review last week's action items:
everyone should look into the finalizer issues if they can
PythonException finalizer update

Notes:
No quorum, meeting canceled

Action Items:
Mark will check if dev work on existing Unity PRs is still in progress (if not, 
please comment on the PR when we expect work to resume)

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, April 8 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/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Python for Unity 4.0.0-exp.5 now available!

2021-04-06 Thread Mark Visser

Hi everyone,

I'm thrilled to announce that Python for Unity has been updated to support the 
latest Python for .NET! This update brings Python 3.7 support and the ability 
to use native Python modules. Well, technically you could use them before; the 
difference is that now Unity won't crash on domain reload if you do. :-)

You can find more details in the official announcement 
<https://forum.unity.com/threads/python-for-unity-release-announcements.1084688/#post-6990848>.

I'm cross-posting here because this release would not have been possible 
without the joint efforts of Unity, Imaginary Spaces and the Python for .NET 
developers. Thank you Amos, Felix, Victor, Benedikt, and Benoit!

cheers,
-Mark

Mark Visser
Senior Dev Manager, M&E
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for April 8, 2021

2021-04-08 Thread Mark Visser

Attendees: Victor, Mark, Felix, Benoit
Agenda:
Review last week's action items:
everyone should look into the finalizer issues if they can
PythonException finalizer update

Notes:
finalizer issues?
not sure what this is referencing, Victor will talk to Benedikt
PythonException finalizer update blocked due to failure on 3.6
Benedikt gave Felix pointers he needed to get unblocked
Victor posted a pull that potentially fixes - this PR #1426 
<https://github.com/pythonnet/pythonnet/pull/1426>
Victor has a bunch of breaking changes he wants to potentially land for 3.0
feature: ability to add mix-ins to .NET types with Python
solves multiple issues with dictionary conversions
avoids having to create a proxy class in C# that doesn't behave like a C# 
dictionary
allows you to create a class that works as a dictionary in both Python and C#
fairly mature, possibly can land before 3.0
feature: change overload resolution to whatever dynamic does in C#
solves problem where overloads behave in a surprising way
barely a proof-of-concept (not even tested/validated/etc)
feature: ability to change base class
others
Victor has many open PRs
https://github.com/pythonnet/pythonnet/pulls/lostmsu 
<https://github.com/pythonnet/pythonnet/pulls/lostmsu>
please review
Have we tested on Apple Silicon
no
Benoit can test
Travis? do we have automated testing on Mac? we do, AMD64 only
we don't have a good debugger for 64-bit ARM
Unity will need Apple Silicon support by November to make our Python package 
officially supported
potentially lots of work
Native code page still there?
no, got removed

Action Items:
Victor to make a list of breaking changes in his branch that could land for 3.0 
and discuss with Benedikt
Felix to review #1426 <https://github.com/pythonnet/pythonnet/pull/1426>
Victor to update Improve Python <-> .NET exception integration 
<https://github.com/pythonnet/pythonnet/pull/1134> 
Victor to update https://github.com/pythonnet/pythonnet/pull/1133 
<https://github.com/pythonnet/pythonnet/pull/1133> and check with Benedikt that 
it's still good to land for 3.0
Benoit to test on Apple Silicon & derisk

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, April 22 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/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for April 22, 2021

2021-04-22 Thread Mark Visser

Attendees: Victor, Mark, Felix, Benoit

Agenda:
Review last week's action items:
Victor to make a list of breaking changes in his branch that could land for 3.0 
and discuss with Benedikt
Felix to review #1426 <https://github.com/pythonnet/pythonnet/pull/1426>
Victor to update Improve Python <-> .NET exception integration 
<https://github.com/pythonnet/pythonnet/pull/1134> 
Victor to update https://github.com/pythonnet/pythonnet/pull/1133 
<https://github.com/pythonnet/pythonnet/pull/1133> and check with Benedikt that 
it's still good to land for 3.0
Benoit to test on Apple Silicon & derisk

Notes:
Improve Python <-> .NET exception integration 
<https://github.com/pythonnet/pythonnet/pull/1134> blocked: waiting for #1426 & 
#1441 to land
Python 3.7 doesn't build on Apple Silicon
fixes won't be backported to 3.7
3.9 is earliest version that will support Apple Silicon

Action Items:
Victor to make a list of breaking changes in his branch that could land for 3.0 
and discuss with Benedikt
Felix to review #1426 <https://github.com/pythonnet/pythonnet/pull/1426> & 
#1441 <https://github.com/pythonnet/pythonnet/pull/1441>
Victor to update https://github.com/pythonnet/pythonnet/pull/1133 
<https://github.com/pythonnet/pythonnet/pull/1133> and check with Benedikt that 
it's still good to land for 3.0

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, May 6 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/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Re: Support for Python v3.9

2021-05-13 Thread Mark Visser

Hi Douglas,

It looks to me like this was fixed in Python 3.6, 3.7, 3.8 and 3.9:

From https://python-security.readthedocs.io/vuln/cjk-codec-download-eval.html: 
<https://python-security.readthedocs.io/vuln/cjk-codec-download-eval.html:>

Fixed In 
<https://python-security.readthedocs.io/vuln/cjk-codec-download-eval.html#fixed-in>
Python 3.6.13 (2021-02-16) fixed by commit e912e94 (branch 3.6) 
<https://github.com/python/cpython/commit/e912e945f2960029d039d3390ea08835ad39374b>
 (2020-10-20)
Python 3.7.10 (2021-02-16) fixed by commit 43e5231 (branch 3.7) 
<https://github.com/python/cpython/commit/43e523103886af66d6c27cd72431b5d9d14cd2a9>
 (2020-10-20)
Python 3.8.7 (2020-12-21) fixed by commit 6c6c256 (branch 3.8) 
<https://github.com/python/cpython/commit/6c6c256df3636ff6f6136820afaefa5a10a3ac33>
 (2020-10-06)
Python 3.9.1 (2020-12-07) fixed by commit b664a1d (branch 3.9) 
<https://github.com/python/cpython/commit/b664a1df4ee71d3760ab937653b10997081b1794>
 (2020-10-06)
So you should be able to address the CVE by upgrading to one of these patch 
versions. AFAIK we don't have a timeline for 3.9 support in Python for .NET yet.

cheers,
-Mark

Mark Visser
Senior Dev Manager, M&E
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

> On May 12, 2021, at 12:43 PM, Douglas Wyant (Aptly Technology Corporation) 
> via PythonNet  wrote:
> 
> PythonNet,
> Hi folks, I have no idea if this is the correct way to engage 
> support / ask questions, so please redirect me.  We need to deploy Python 
> v3.9 to resolve a known Security issue in older versions.  I’m told we’re 
> blocked on deploying until PythonNet is updated to support v3.9.  So the 
> question is when might that be?
>  
> https://bugs.python.org/issue41944 <https://bugs.python.org/issue41944>
> CVE-2020-27619: WIndows
> Python versions 3.0.0 through 3.9.0 are susceptible to a vulnerability which 
> when successfully exploited could lead to disclosure of sensitive 
> information, addition or modification of data, or Denial of Service (DoS).
> Affected Versions 
> Python versions 3.0.0 through 3.9.0 
>  
> Thanks,
>  
> Doug Wyant (Aptly Technology Corporation), GSEC, GCIH
> Service Engineer 2
> Microsoft
> ___
> PythonNet mailing list -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected] 
> <mailto:[email protected]>
> https://mail.python.org/mailman3/lists/pythonnet.python.org/ 
> <https://mail.python.org/mailman3/lists/pythonnet.python.org/>
> Member address: [email protected] <mailto:[email protected]>
___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for June 17, 2021

2021-06-21 Thread Mark Visser

Attendees: Amos, Mark, Felix, Victor

Agenda:
Review last week's action items:
Victor to make a list of breaking changes in his branch that could land for 3.0 
and discuss with Benedikt
Felix to review #1426 <https://github.com/pythonnet/pythonnet/pull/1426> & 
#1441 <https://github.com/pythonnet/pythonnet/pull/1441>
Victor to update https://github.com/pythonnet/pythonnet/pull/1133 
<https://github.com/pythonnet/pythonnet/pull/1133> and check with Benedikt that 
it's still good to land for 3.0
Amos concerned about performance

Notes
#1426 <https://github.com/pythonnet/pythonnet/pull/1426> & #1441 
<https://github.com/pythonnet/pythonnet/pull/1441> merged
possibility of performance improvements in bindings
https://github.com/topameng/tolua <https://github.com/topameng/tolua> bindings 
perform much better than Python for .NET
Victor: please add any missing coverage to performance tests so we can catch 
regressions
Amos: there is room for improvement in Python .NET performance
code gen to improve performance?
will likely introduce breaking changes
I have a branch already that improves performance
Victor: if it's not risky and can be ported to current master it could go into 
3.0 (no sooner than September)
Victor: make a PR against master branch and describe the breaking changes
import refactor almost done, waiting for Benedikt to review

Action Items:
Victor to make a list of breaking changes in his branch that could land for 3.0 
and discuss with Benedikt
Victor to update https://github.com/pythonnet/pythonnet/pull/1133 
<https://github.com/pythonnet/pythonnet/pull/1133> and check with Benedikt that 
it's still good to land for 3.0
Amos to create a PR to master with bindings performance improvements
Benedikt to review https://github.com/pythonnet/pythonnet/pull/1369 Modernize 
import hook <https://github.com/pythonnet/pythonnet/pull/1369>

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, July 8 at 2pm EST (click for your 
time zone) <https://www.google.com/search?q=2%3A00+pm+EST>.


Mark Visser
Senior Dev Manager, M&E
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for July 8, 2021

2021-07-08 Thread Mark Visser

Attendees: Amos, Mark, Victor

Agenda:
Review last week's action items:
Victor to make a list of breaking changes in his branch that could land for 3.0 
and discuss with Benedikt
Victor to update https://github.com/pythonnet/pythonnet/pull/1133 
<https://github.com/pythonnet/pythonnet/pull/1133> and check with Benedikt that 
it's still good to land for 3.0
Amos to create a PR to master with bindings performance improvements
Benedikt to review https://github.com/pythonnet/pythonnet/pull/1369 Modernize 
import hook <https://github.com/pythonnet/pythonnet/pull/1369>
Notes
Victor opened PRs for breaking changes that could land for 3.0, already in 
review
will continue working on these 
#1133 __name__ and __signature__ for .NET methods 
<https://github.com/pythonnet/pythonnet/pull/1133> will stay as is for now, not 
important
 #1369 Modernize import hook <https://github.com/pythonnet/pythonnet/pull/1369> 
has been merged
PR with bindings performance improvements has a lot of conflicts, taking longer 
than expected
Victor suggested porting changes to master one at a time rather than trying to 
resolve conflicts

Action Items:
Victor will continue working on PRs for breaking changes that could land for 3.0
Amos will continue working on porting performance improvements to master

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, July 22 at 2pm EST (click for your 
time zone) <https://www.google.com/search?q=2%3A00+pm+EST>.

Mark Visser
Senior Dev Manager, M&E
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Re: Support for Python v3.9

2021-07-22 Thread Mark Visser

Hi Di & other folks,

Just quoting Benedikt from earlier in the thread in case it was missed:

> Hi,
> 
> Indeed, we back-ported support as such in Python.NET <http://python.net/> 
> 2.5.2, but we ran into some ominous crashes in CI. That's why we don't claim 
> support on Pypi and don't provide wheels for 3.9. You can either build 2.5.2 
> yourself or the try to use the current master instead. We'll try to come up 
> with a concrete roadmap for the 3.0 release in one of the next biweekly 
> meetings.
> 
> Regards
> Benedikt

To summarize, Python.NET <http://python.net/> does NOT support Python 3.9.x at 
this time. Python.NET <http://python.net/> is an open-source project with a 
very small number of part-time volunteer maintainers, so any investigation 
you're able to do on Python 3.9 is appreciated. If you're able to reproduce 
crashes, please log them as issues at 
https://github.com/pythonnet/pythonnet/issues 
<https://github.com/pythonnet/pythonnet/issues>. If you're able to commit 
development resources to fixing crashes, even better! Pull requests are always 
welcome!

cheers,
-Mark



> On Jul 8, 2021, at 2:10 PM, Di Yang (PACTERA TECHNOLOGIES INC) via PythonNet 
>  wrote:
> 
> Hi Vince/Pythonnet,
>  
> I tested again with Python 3.9.6 which is released on 6/28, still got error 
> when running “pip install pythonnet”.  I got the same error on two machines. 
> How could we solve it?
> 
>  
> Thanks,
> Di
>  
> From: Vince Luff  
> Sent: Saturday, May 15, 2021 4:19 AM
> To: A list for users and developers of Python.NET 
> Cc: Di Yang (PACTERA TECHNOLOGIES INC) ; Douglas Wyant 
> (Aptly Technology Corporation) 
> Subject: [EXTERNAL] Re: [Python.NET] Re: Support for Python v3.9
>  
> Hi guys,
>  
> Am I missing something here, because Python.Net v2.5.2 already supports 
> Python 3.9:
>  
> https://github.com/pythonnet/pythonnet/releases 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpythonnet%2Fpythonnet%2Freleases&data=04%7C01%7Cv-diyan%40microsoft.com%7Cf693f50050c04d3878ea08d91793480b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637566744677417311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OEVv80uryS4cAJj%2FVg3G1vn93T63vegHPQt2dbrYgaY%3D&reserved=0>
>  
> "Additionally, includes support for Python 3.9"
>  
> Regards,
> Vince
> From: Mark Visser mailto:[email protected]>>
> Sent: 13 May 2021 17:14
> To: A list for users and developers of Python.NET  <mailto:[email protected]>>
> Cc: Di Yang (PACTERA TECHNOLOGIES INC)  <mailto:[email protected]>>; Douglas Wyant (Aptly Technology Corporation) 
> mailto:[email protected]>>
> Subject: [Python.NET] Re: Support for Python v3.9
>  
> Hi Douglas, 
>  
> It looks to me like this was fixed in Python 3.6, 3.7, 3.8 and 3.9:
>  
> From 
> https://python-security.readthedocs.io/vuln/cjk-codec-download-eval.html: 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpython-security.readthedocs.io%2Fvuln%2Fcjk-codec-download-eval.html%3A&data=04%7C01%7Cv-diyan%40microsoft.com%7Cf693f50050c04d3878ea08d91793480b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637566744677427307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aS%2BV4jyLy5IzjSMrU%2F%2FtmHzJyDFKLKS6kfi2qG8l45Q%3D&reserved=0>
>  
> 
> Fixed In
> 
> · Python 3.6.13 (2021-02-16) fixed by commit e912e94 (branch 3.6) 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fcommit%2Fe912e945f2960029d039d3390ea08835ad39374b&data=04%7C01%7Cv-diyan%40microsoft.com%7Cf693f50050c04d3878ea08d91793480b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637566744677437300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Plm8%2FnyOjoFqSGlnoi3x7K59r2w3dTRuHMtGWQCsr40%3D&reserved=0>
>  (2020-10-20)
> · Python 3.7.10 (2021-02-16) fixed by commit 43e5231 (branch 3.7) 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fcommit%2F43e523103886af66d6c27cd72431b5d9d14cd2a9&data=04%7C01%7Cv-diyan%40microsoft.com%7Cf693f50050c04d3878ea08d91793480b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637566744677447302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WSKZuaaaIjiBLv9GZt8rE%2BTfx8tB5lsktar77Wl1AeU%3D&reserved=0>
>  (2020-10-20)
> · Python 3.8.7 (2020-12-21) fixed by commit 6c6c256 (branch 3.8) 
> <https://nam06.safelinks.protection.outlook.com/?url=h

[Python.NET] Working group notes for July 22, 2021 - no meeting

2021-07-22 Thread Mark Visser

Quorum not met, meeting cancelled.
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, August 5 at 2pm EST (click for your 
time zone) <https://www.google.com/search?q=2%3A00+pm+EST>.

Mark Visser
Senior Dev Manager, M&E
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for September 2, 2021

2021-09-02 Thread Mark Visser

Attendees: Victor, Benedikt, Mark

Agenda:
Review previous action items:
Victor will continue working on PRs for breaking changes that could land for 3.0
Amos will continue working on porting performance improvements to master
"We'll try to come up with a concrete roadmap for the 3.0 release in one of the 
next biweekly meetings."
Python 3.9 on the mailing list
Github Discussions feature
https://github.com/pythonnet/pythonnet/pull/1402 
<https://github.com/pythonnet/pythonnet/pull/1402> blocked by issue #1412 
<https://github.com/pythonnet/pythonnet/issues/1412>
Notes
Release candidate for 3.0
next step is a preview build 
need to groom 3.0 milestone
need to decide on breaking API changes for 3.0 - last chance to break API
python wheel build needs to be fixed
can't run 32-bit in CI because dotnet clr doesn't support 32-bit
Unity does not support 32 bit
would be nice if we can run ARM in CI
Python 3.9 is not supported on 2.5 branch
if anyone wants to work on this they are welcome to do so (on 2.5 branch) but 
we have no plans to support on 2.5
we know it crashes, non-trivial to debug
support will come in 3.0 (master branch)
Github Discussions
let's wait and see

Action Items:
Victor will go through issues to select ones for 3.0
Victor will work on memory leaks
Benedikt will look into running 32 bit builds in CI
Mention we do not officially support 32 bit yet

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, September 30 at 2pm EST (click for 
your time zone) <https://www.google.com/search?q=2%3A00+pm+EST>.

___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Working group notes for January 20, 2022

2022-01-20 Thread Mark Visser

Attendees: Victor, Mark

Agenda:
Review previous action items:
Benedikt will review References PR 
<https://github.com/pythonnet/pythonnet/pull/1603> over weekend
If no comments Victor will merge References PR 
<https://github.com/pythonnet/pythonnet/pull/1603>
Benedikt will release alpha 2 after References PR 
<https://github.com/pythonnet/pythonnet/pull/1603> is merged
Walk through open issues for 3.0.0 milestone

Notes
Unity update:
current Python is 3.7, and they are migrating to 3.9
will take a look at https://github.com/pythonnet/pythonnet/pull/1402 
<https://github.com/pythonnet/pythonnet/pull/1402>
will move to master / 3.0.0 "soon"
if you don't hear from us in the next 2 weeks, go ahead with the release
no quorum

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 3 at 2pm EST (click for 
your time zone) <https://www.google.com/search?q=2%3A00+pm+EST>.

Mark Visser
Senior Dev Manager, M&E
Unity Technologies - www.unity3d.com <http://www.unity3d.com/>






___
PythonNet mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Re: BadImageFormatException or FileNotFoundException- pythonnet and AlphaVSS

2022-07-11 Thread Mark Visser

+1 - in the past I've used https://www.dependencywalker.com/ 
 to figure out the problem. On mac you can 
use otool -L, and on linux you can use ldd.

> On Jul 11, 2022, at 9:38 AM, Alex Earl  wrote:
> 
> Sometimes the file not found error occurs because a dependency of the dll can 
> not be found. 
> 
> On Sun, Jul 10, 2022, 20:06 Steven Manross  > wrote:
> Howdy all,
> 
>  
> 
> I am somewhat new to pythonnet and .NET programming, and just joined the 
> mailing list.  You have my apologies if I am missing something simple.  I am 
> aware that BadImageFormatException suggests that I’m trying to open an x64 
> DLL on a 32-bit OS or python installation (or vice versa), but neither seem 
> to be the case (that I can tell).  Depending on exactly how I call the code, 
> I get a File Not Found or Bad Image Exception.
> 
>  
> 
> The File Not Found is interesting since the files live in the same directory 
> as a working DLL (AlphaVSS.Common works - built to run on any architecture, 
> AlphaVSS.x64 doesn’t).
> 
>  
> 
> Specifics:
> 
> * Python 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 
> bit (AMD64)] on win32
> 
> * uninstalled Python 3.10 temporarily so I cant get you that detail (sorry)
> 
> * And the Windows version clearly states it’s Windows Server 2016 x64
> 
>  
> 
> I’m doing my testing from ipython.
> 
>  
> 
> The code below was tested with Python 3.9 x64 (pythonnet 2.5.2 via wheel 
> file) and Python 3.10 x64 (installed pythonnet 3.0.0-dev1 from git master a 
> few days ago) on Windows Server 2016 x64 Evaluation patched for current .NET 
> Frameworks 2022-06 and both produce an error on the following code.
> 
>  
> 
> AlphaVSS DLLs were generated via powershell/nuget, and I just copied the DLLs 
> from my powershellmodules dir to the “clr_dir” below for testing 
> (documentation suggests you copy the files to the same directory for use).  
> This DLL was created for .NET Framework 4.5 and I’ve installed Framework 4.8 
> and this Cumulative update:
> 
>  
> 
> 2022-06 Cumulative Update for .NET Framework 4.8 for Windows Server 2016 for 
> x64 (KB5014630)
>  
> 
> This code is eventually intended to manipulate the Volume Shadow Copy Service 
> on Windows.  I am aware that there is limited functionality for ShadowCopies 
> from DISKSHADOW and WMI, but wanted to get more functionality from this VSS 
> .NET Library (specifically Shadow Copy Sets), and pythonnet seemed like a 
> great way to implement this code in my favorite scripting language.
> 
>  
> 
> Here is the documentation for the DLLs (version 2.0.0) if anyone wants that:
> 
> https://alphavss.alphaleonis.com/api/Alphaleonis.Win32.Vss.html 
> 
>  
> 
> git source:
> 
> https://github.com/alphaleonis/AlphaVSS 
> 
>  
> 
> I double checked permissions on the DLLs and I have full control as the 
> administrator.  UAC is completely turned off on this machine (if it matters).
> 
>  
> 
> Any suggestions would be appreciated.  This is a test system, so I can do 
> just about anything to it including rebuilding it from scratch as it was 
> built specifically for testing this.  This is a VM on Hyper-V 2016 (I doubt 
> that matters).
> 
>  
> 
> Thank you for your time!
> 
>  
> 
> Steven
> 
> #   ipython dir output
> In [16]: ! dir "c:\users\administrator\desktop\alphavss"
> 
> Volume in drive C has no label.
> 
> Volume Serial Number is 8C70-F8A3
> 
>  
> 
> Directory of c:\users\administrator\desktop\alphavss
> 
>  
> 
> 07/09/2022  03:10 AM  .
> 
> 07/09/2022  03:10 AM  ..
> 
> 12/03/2019  08:37 PM69,632 AlphaVSS.Common.dll
> 
> 12/03/2019  08:37 PM21,408 AlphaVSS.Common.pdb
> 
> 12/03/2019  08:37 PM   618,522 AlphaVSS.Common.xml
> 
> 12/03/2019  08:37 PM   325,120 AlphaVSS.x64.dll
> 
> 12/03/2019  08:37 PM   271,872 AlphaVSS.x86.dll
> 
> 12/03/2019  08:29 PM   342,392 Ijwhost.dll
> 
> 07/09/2022  03:09 AM  runtimes
> 
> 07/09/2022  03:10 AM  win-x64
> 
> 07/09/2022  03:10 AM  win-x86
> 
>  
> 
> # code
> 
> import sys
> 
> import clr
> 
> import System
> 
> # from System import Reflection
> 
>  
> 
> clr_dir = "C:\\Users\\Administrator\\Desktop\\AlphaVSS"
> 
> if clr_dir not in sys.path:
> 
> sys.path.append(clr_dir)
> 
>  
> 
> # common_vss = Reflection.Assembly.LoadFile(f'{clr_dir}\\AlphaVSS.Common.dll')
> 
> clr.AddReference("AlphaVSS.Common") #pylint:disable=I1101
> 
>  
> 
> import Alphaleonis.Win32.Vss as alphavss
> 
>  
> 
>  
> 
> # clr.AddReference("AlphaVSS.x64") #pylint:disable=I1101
> 
> vss = alphavss.VssFactoryProvider.Default
> 
> # x64_vss = Reflection.Assembly.LoadFile(f'{clr_dir}\\AlphaVSS.x64.dll')
> 
> # BadImageFormatException: An attempt was made to load a program with an 
> incorrect format. (Exception from HRESULT: 0x

[Python.NET] import failing help needed

2023-02-12 Thread Mark A Gregory

Windows 11. Visual Studio 2022. Python311 install and working using VSCode. 
Pythonnet installed using VS 2022 nuget and pip3 in command prompt
I have this code and it is failing at import pyproj - error is no _socket

Help appreciated

public AzimuthBoundingBoxCalculator()
{
string? GetPythonLib()
{
if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
{
return 
"/Library/Frameworks/Python.framework/Versions/3.11/lib/libpython3.11.dylib";
}
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
return 
@"C:\Users\basic\AppData\Local\Programs\Python\Python311\python311.dll";
}
if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux)
|| RuntimeInformation.IsOSPlatform(OSPlatform.FreeBSD))
{
return "libpython3.11.so";
}

return null;
}
string pythonDll = GetPythonLib();
Runtime.PythonDLL = pythonDll;
Environment.SetEnvironmentVariable("PYTHONNET_PYDLL", pythonDll);
PythonEngine.Initialize();
_gilState = Py.GIL();
using (Py.GIL())
{
dynamic pyproj = Py.Import("pyproj");
_geod = pyproj.Geod(ellps: "WGS84");
}
}


Regards
Mark Gregory

___
Python.NET mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pythonnet.python.org/
Member address: [email protected]

[Python.NET] Re: intermittent importerror unknown location, module imported as namespace, import from clr works

2020-04-09 Thread Dr. Mark Alexander Mikofski PhD

Good idea, but it doesn't seem to work consistently. It worked the first
time I compiled it, but then wouldn't work again, similar to the behavior I
was already seeing. I don't think adding the other frameworks to
 had any effect in this particular situation, b/c I am
compiling from the x64 native tools command prompt for vs2019 using csc.exe
so I think I'm using the default .NET framework, but I don't know for sure.
If I check where csc I can see it's calling from
"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\MSBuild\Current\Bin\Roslyn\csc.exe"

If I add net45, net46, or net461 or any combination to the project, when I
load the solution in Visual Studio, it doesn't reference dotnet core
anymore, or any framework. So any symbols from System are unreferenced.
Maybe I need to add the reference to other frameworks from the project
inside Visual Studio.

The behavior is so intermittent, I can't make it work consistently. One
thing I've noticed, is that when it does work, the module representation is:

and when it doesn't it's representation is:

Anyway, for the meantime this workaround does seem to work consistently:
```
from clr import pv
```
so I guess I'll have to do that or do as you did and just switch the
project to a .NET Framework.

Thanks!

On Thu, Apr 9, 2020 at 4:17 PM Emmanuel Rutovic  wrote:

> Hi Mark,
>
> My understanding (and I might be wrong) is Pythonnet (Official Compiled
> Master branch) is *not* compatible with .Net Core and is compatible only
> with the .Net framework. Is it possible that you accidentally load .Net
> Framework libraries when you think they are .Net Core ?
> I spent a lot of time with a similar problem and I finally decided to
> compile my project also for .Net framework :
>
> .csproj:
>
>   
> netcoreapp3.1;net472
>   
>
> There are forks that are supposed to be compatible with .Net Core but I
> wasn't able to make them work either.
>
> I hope it helps,
> Emmanuel.
>
>
> On Thu, Apr 9, 2020 at 12:46 PM Mark Mikofski 
> wrote:
>
>> Sorry for starting a new thread if redundant. I have been a long time
>> user of PythonNet and suddenly I am having an intermittent failure that I
>> can't diagnose,
>>
>> PythonNet == 2.4.0.dev0 from pypi in Conda
>> Python == 3.7.6 from conda main channel
>> msvc 2019
>>
>> I am using the following repository:
>> https://github.com/mikofski/pv.net
>>
>> When I try to import pv.SolarPosition I get the following error:
>>
>> ImportError: cannot import name 'SolarPosition' from 'pv' (unknown
>> location)
>>
>> I've tried it a couple of ways:
>>
>> 1. add reference to assembly name, doesn't work
>> >>> import clr
>> >>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll"
>> >>> assy = clr.AddReference(assy_path)
>> >>> import pv
>> >>> pv
>> 
>> >>> pv.SolarPosition
>> AttributeError: module 'pv' has no attribute 'SolarPosition'
>> >>> from pv import SolarPosition
>> ImportError: cannot import name 'SolarPosition' from 'pv' (unknown
>> location)
>>
>> 2. add assembly path to PYTHONPATH or sys.path, neither works
>> >>> import sys
>> >>> assy_path = "C:\\Users\\mikm\\source\\repos\\pv.net\\bin"
>> >>> sys.path.append(assy_path)
>> >>> import clr
>> >>> assy = clr.AddReference("pv")
>> >>> import pv
>> >>> pv
>> 
>> >>> pv.SolarPosition
>> AttributeError: module 'pv' has no attribute 'SolarPosition'
>> >>> from pv import SolarPosition
>> ImportError: cannot import name 'SolarPosition' from 'pv' (unknown
>> location)
>>
>>
>> 3. import from clr, always works
>> >>> import clr
>> >>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll"
>> >>> assy = clr.AddReference(assy_path)
>> >>> from clr import pv
>> >>> pv
>> 
>> >>> pv.SolarPosition
>> pv.SolarPosition
>> >>> dates = ["19900101T12:30:00", "19900102T12:30:00",
>> "19900103T12:30:00", "19900104T12:30:00"]
>> >>> pv.SolarPosition(dates, 32.1, -121.0)
>> 19900101T12:30:00 --> 1/1/1990 12:30 PM
>> 19900102T12:30:00 --> 1/2/1990 12:30 PM
>> 19900103T12:30:00 --> 1/3/1990 12:30 PM
>> 19900104T12:30:00

[Python.NET] How do you add an element to a List in a read-only property?

[Python.NET] Re: Accessing a list that is a read-only property?

[Python.NET] Accessing a list that is a read-only property?

[Python.NET] Working group notes for March 26, 2020

[Python.NET] intermittent importerror unknown location, module imported as namespace, import from clr works

[Python.NET] Re: intermittent importerror unknown location, module imported as namespace, import from clr works

[Python.NET] Working group notes for May 7, 2020

[Python.NET] Re: Working group notes for May 7, 2020

[Python.NET] Working group notes for May 21, 2020

[Python.NET] Working group notes for June 4, 2020

[Python.NET] Working group notes for July 16, 2020

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

[Python.NET] Working group notes for August 13, 2020

[Python.NET] Working group notes for November 5, 2020

[Python.NET] Working group notes for January 14, 2021

[Python.NET] Working group notes for February 11

[Python.NET] Working group notes for March 11, 2021

[Python.NET] Working group notes for March 25, 2021

[Python.NET] Python for Unity 4.0.0-exp.5 now available!

[Python.NET] Working group notes for April 8, 2021

[Python.NET] Working group notes for April 22, 2021

[Python.NET] Re: Support for Python v3.9

[Python.NET] Working group notes for June 17, 2021

[Python.NET] Working group notes for July 8, 2021

[Python.NET] Re: Support for Python v3.9

[Python.NET] Working group notes for July 22, 2021 - no meeting

[Python.NET] Working group notes for September 2, 2021

[Python.NET] Working group notes for January 20, 2022

[Python.NET] Re: BadImageFormatException or FileNotFoundException- pythonnet and AlphaVSS

[Python.NET] import failing help needed

[Python.NET] Re: intermittent importerror unknown location, module imported as namespace, import from clr works

31 matches

Site Navigation

Mail list logo

Footer information