Pavel Koneski
Pavel Koneski
Interestingly, it works fine in ipy3.
Sorry, false alarm , I see label "core" now.
It seems that on .NET Core, `Enumerable` extensions are exported by `System.Core.dll`, and by `System.Linq.dll`. Therefore there are two identical ambiguous targets, each one comes from a different assembly. The...
@slozier I think I agree with you: if two or more assemblies export extension methods with the same signature, then it is a legitimate "ambiguous call" case and the error...
> * Could a language opt-in to such a behaviour or would it be stuck with whatever we choose? I suppose we could add a (few) new protected virtual method(s)...
> it seems like some overloads in ObjectOperations would be useful This is my preferred approach too (over IronPython specific), but I am having second thoughts about simply overloading `Invoke`...
The codebase contains some sample code that perhaps addresses most of your questions: a sample module [`xxsubtype`](https://github.com/IronLanguages/ironpython3/blob/master/Src/IronPython.Modules/xxsubtype.cs). I see that it uses a few (nonessential) internal methods, so perhaps it...
> Other question that comes to mind is does this behave the same way for non-extension methods? Yes, it does. > I'm not super familiar with the method resolution code...
From memory, the place looks about right. However I see that it will try to convert any Python function to a .NET function with one parameter. Using your modified code,...
> this raises a `TypeError` and then breaks subsequent calls to the "good" lambda: The way the overload resolver works is that it caches results of previous resolutions for a...