Skip to content

Unable to modify C# List<T> #1153

Closed
Closed

Description

@jfu334

Environment

  • Pythonnet version: 2.4.0
  • Python version: 3.6
  • Operating System: windows 10

Details

I have a C# class like this:

public class X
{
  public List<string> list;
}

I'm unable to do useful stuff with X.list due to the automatic value conversion of pythonnet.

Preface:

pylist=["a", "b", "c"]
x=X()
x.list=System.Collections.Generic.List[str]()

Doesnt work:

x.list=System.Collections.Generic.List[str](pylist)

Doesnt work:

for i in pylist:
  x.list.Add(i)

Doesnt work:

for i in pylist:
  x.list.append(i)

x.list is always empty except for the .Add call, with throws Exception cause the value is converted to python list. How do I modify a C# List in python?

Activity

  1. filmor commented on May 25, 2020

    @filmor
    Member

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

  2. jfu334 commented on May 25, 2020

    @jfu334
    Author

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

  3. filmor commented on May 25, 2020

    @filmor
    Member

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

  4. jfu334 commented on May 25, 2020

    @jfu334
    Author

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

  5. jfu334 commented on May 25, 2020

    @jfu334
    Author

    ... confirmed. The code:

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

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

  6. filmor commented on May 25, 2020

    @filmor
    Member

    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?

  7. jfu334 commented on May 25, 2020

    @jfu334
    Author

    Thanks for the fast response!

  8. lostmsu commented on May 26, 2020

    @lostmsu
    Member

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

  9. koliyo commented on Mar 8, 2021

    @koliyo

    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?

  10. lostmsu commented on Mar 9, 2021

    @lostmsu
    Member

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

  11. richard-gemmell-42 commented on Mar 30, 2021

    @richard-gemmell-42

    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

  12. lostmsu commented on Mar 30, 2021

    @lostmsu
    Member

    @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.

  13. lostmsu commented on Sep 23, 2021

    @lostmsu
    Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions