You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How about the following idea: we could reuse the work that the DLR has already done to support correct overloading resolution (for IronPython). To use that we would first convert the Python arguments to their corresponding .NET types and then let the DLR decide which of the overloads to pick. This should add support for named arguments, generic type inference, etc.
I tinkered with this a bit and I think it would work correctly, but it would be a fairly major piece of work. Do you think this is a worthwhile route to pursue? It would add a reference to https://github.com/IronLanguages/dlr to python.net by adding this NuGet package https://www.nuget.org/packages/DynamicLanguageRuntime/
@ArvidJB this is interesting suggestion. One problem I see is that conversion from Python to .NET types can still be ambiguous even before letting DLR to do the overloading resolution. For example, passing a float could be converted to a single or a double, passing an integer could be converted to int16, int32, or int64.
Here are some comments from @matthid where he suggested to use Roslyn for this:
@denfromufa, you haven't listed "named arguments".
I guess it is not support by @ArvidJB's comment.
Our experience at QuantConnect is that it is not. Could you please confirm?
Activity
ArvidJB commentedon Dec 27, 2016
How about the following idea: we could reuse the work that the DLR has already done to support correct overloading resolution (for IronPython). To use that we would first convert the Python arguments to their corresponding .NET types and then let the DLR decide which of the overloads to pick. This should add support for named arguments, generic type inference, etc.
I tinkered with this a bit and I think it would work correctly, but it would be a fairly major piece of work. Do you think this is a worthwhile route to pursue? It would add a reference to https://github.com/IronLanguages/dlr to python.net by adding this NuGet package https://www.nuget.org/packages/DynamicLanguageRuntime/
den-run-ai commentedon Jan 6, 2017
@ArvidJB this is interesting suggestion. One problem I see is that conversion from Python to .NET types can still be ambiguous even before letting DLR to do the overloading resolution. For example, passing a float could be converted to a single or a double, passing an integer could be converted to int16, int32, or int64.
Here are some comments from @matthid where he suggested to use Roslyn for this:
#203 (comment)
AlexCatarino commentedon Feb 16, 2018
@denfromufa, you haven't listed "named arguments".
I guess it is not support by @ArvidJB's comment.
Our experience at QuantConnect is that it is not. Could you please confirm?
den-run-ai commentedon Feb 16, 2018
@AlexCatarino probably not, can you provide a failing case not working for you?
jaredbroad commentedon Feb 16, 2018
Fairly specific to our API but: it silently defaults as if the named args aren't there.
In the working case the trade occurs at 4.01am; in the default case its 9.31am.
https://www.quantconnect.com/terminal/processCache/?request=embedded_backtest_fa3f24864893dd26a7ed8d5a7d23a336.html
den-run-ai commentedon Dec 9, 2018
One more method overloading issue:
https://stackoverflow.com/questions/53642088/python-using-pythonnet-to-call-a-dll-function-c-which-expects-type-arraylis
provide detailed error message, when an overload can't be found when …
provide detailed error message, when an overload can't be found when …
Improve "No method matches given arguments" message with more details (…
Improve "No constructor matches given arguments" message with more de…
Improve "No constructor matches given arguments" message with more de…
Improve "No method matches given arguments" message with more details (…
Improve "No constructor matches given arguments" message with more de…