Denis,

I like the idea of empowering the user to customize/extend/disable the method resolution logic. I find that IronPython's resolution isn't always ideal for our use cases. For example we have methods which take IEnumerable<double> and this usage is currently rejected by IronPython:

Obj.Func([1,3,4])

while this works

Obj.Func([1.,3.,4.])

I am not saying that IronPython is wrong but that as an API designer I'd like the option to choose to allow the former for all of my IEnumerable<double> methods or even to customize the resolution at the granularity of individual methods/classes where we decide that is the appropriate "User Experience".

I see a unit test on master with the .Overloads method being called from python but this is useful for me only as a workaround. We aim to present a clean API to our scripting users who often are not experienced programmers.

Thanks,

Mohamed Koubaa

ANSYS Inc

On Mon, Sep 24, 2018 at 9:20 AM Denis Akhiyarov <denis.akhiyarov@gmail.com> wrote:

This link below is probably a good staring point for "TypeError: No method matches given arguments". But ideally we should bring back the skipping of method resolution logic within a context manager whenever the user knows what he/she is doing. There is also explicit `.Overloads` option to force through one of the overloaded methods.

https://github.com/pythonnet/pythonnet/issues/265

On Thu, Aug 2, 2018 at 10:11 AM Mohamed Koubaa <mohamed.koubaa@ansys.com> wrote:
Hello,

I am using the 2.3 release branch.

I have C# code like this:
public class A {
public A() {...}
}

public class B {
public B() {...}
public static void Func(IEnumerable<A> input){
}
}

I want to pass in a python list to Func but get this error:
>>> b=B()
>>> b.Func([A(), A()])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: No method matches given arguments

I tried both IEnumerable and IList in the signature of 'Func'. I know that I can import System and create some .NET collection type and it works well.

Did I miss anything? Is this usage pattern within the design goals of pythonnet? I assume this would have to be fixed in MethodBinder but I wanted to try asking here first.

Thanks!
Mohamed Koubaa
_________________________________________________
Python.NET mailing list - PythonDotNet@python.org
https://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________
Python.NET mailing list - PythonDotNet@python.org
https://mail.python.org/mailman/listinfo/pythondotnet