The .Add call works. What is the exact error you get there?

AttributeError: 'list' object has no attribute 'Add'

And you are absolutely certain that X is indeed an object of your C# class?

Yes absolutely sure. I'd guess the detail here is that the List is retrieved through accessing the field of X.

... confirmed. The code:

l=System.Collection.Generic.List[str]()
l.Add(...)

works. But not for x.list. So at least I have a workaround.

Yes, you are right. There is some work going on to make these conversions optional. @lostmsu Could you chime in on how to exactly do that in this situation?

Thanks for the fast response!

@jfu334 sorry for late response. You should check out the new test for RawProxyEncoder.
Mind the __namespace__ element in the code class definition.

So if I understand correctly, the #1122 pull request allows the workaround with the local list l, but still not possible to call x.list.Add(...)

Any update on if this should be expected to be fixed, or is the solution unknown for this use case?

No, it should work in the x.list.Add(...) scenario.

First of all, I'd like to say that this project is awesome and I really appreciate the work that you've all put into it. Thanks.

The automatic conversion from IList'1 to a native python list causes another problem for us. There isn't a matching conversion from a native python list to an IList'1 so you can't 'round trip' a property value like this:

  values = x.List
  x.List = values  # fails as value is the wrong type

If x.List is declared to be of type IList rather than List then the behaviour is even more baffling. The value returned by x.List now depends on the type of the concrete object assigned to List and not the function prototype. If I assign a List to it then I get a python list back but if I assign a custom class which implements IList to it then I don't. This means that I can't tell the user what type of object to expect when the call x.List.

The design would be less surprising if:

• conversions were always bi-directional (List <==> python list and vice versa)
• the conversion depends on the function being called not on the concrete type of the objects involved

I appreciate that it's probably difficult to change the design at this point but I thought I'd point it out.

In the mean time, I'm trying to use a RawProxyEncoder to disable the conversion from List. Unfortunately this triggers a stack overflow. Please see the link to issue #1427 above.

I wasn't sure these comments were worth another ticket so I thought I'd add them here. Please let me know if you think I should raise another ticket.

cheers,
Richard

@richard-gemmell-42 I actually have a better design in my company's fork: when seen from Python .NET collection types have extra base classes (aka mixins), that implement Pythonic members using .NET members. See for example

https://github.com/losttech/pythonnet/blob/cae2d32729a35fb31f53fd694464f5c44392b896/src/runtime/Mixins/collections.py#L36

I am planning to upstream that feature before 3.0 is released.

C# Lists are no longer automatically converted to Python list in Python.NET 3.0, but still behave like list does.