Repository navigation
meta-issue: overloading improvements #265
Description
- ref/out [WIP] handling ByRef arguments for method overloading - update methodbinder.cs #227
- constructor Constructor argument matching supports simple int to (float|double) types #239 Constructor failing argument matching, silently selects default constructor #238
- subtypes Pythonnet 2.1 not identifying System.Object type #203
- add content manager to completely ignore type checking for overloading Error with Enum GCHandleType.Pinned #174 (comment)
- fix tests when only type-checking with only one method available (no overloading) method overloading - more fun #190
- default arguments .NET default arguments don't work #80
- unsigned Selecting overloaded methods with unsigned integer argument fails #283
- params Calling 'params' method with single argument fails #331
- named/keyword arguments
Activity
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?@AlexCatarino probably not, can you provide a failing case not working for you?
Fairly specific to our API but: it silently defaults as if the named args aren't there.
class BasicTemplateAlgorithm(QCAlgorithm): def Initialize(self): self.SetStartDate(2013,10,07) #Set Start Date self.SetEndDate(2013,10,11) #Set End Date self.SetCash(100000) #Set Strategy Cash self.AddEquity("SPY", Resolution.Minute, market=Market.USA, fillDataForward=False, leverage=1, extendedMarketHours=True) #self.AddEquity("SPY", Resolution.Minute, Market.USA, True, 1, True) def OnData(self, data): if not self.Portfolio.Invested: self.LimitOrder("SPY", 100, 200)In the working case the trade occurs at 4.01am; in the default case its 9.31am.
One more method overloading issue:
- added a commit that references this issue
on Feb 11, 2019 - added a commit that references this issue
on Jun 26, 2019 - added a commit that references this issue
on Jun 28, 2019 - added a commit that references this issue
on May 14, 2020 - added a commit that references this issue
on May 14, 2020 - added a commit that references this issue
on Jun 18, 2020 - added a commit that references this issue
on Jun 29, 2020
