Fix method name parsing in NoMethodMatchPythonExceptionInterpreter

[jhonabreul]

Description

NoMethodMatchPythonExceptionInterpreter builds a user-facing message that names the method that failed overload resolution. It extracted that name with LastIndexOf(" "), which returns the last space-delimited token of the pythonnet message rather than the method name. The pythonnet message has the form:

No method matches given arguments for RSI: (<class 'QuantConnect.Symbol'>, <class 'int'>, <class 'QuantConnect.Resolution'>)

so the last token is a fragment of the argument-type list (e.g. 'QuantConnect.Resolution'>)), producing a garbled message:

...ensure each parameter type matches those required by the 'QuantConnect.Resolution'>) method. Please checkout the API documentation.

The method name is now parsed from between the "for " keyword and the following ":", yielding the correct RSI / SetCash etc.

Related Issue

N/A — bug found while running a Python algorithm whose initialize called self.rsi(symbol, 15, Resolution.DAILY) (the third argument should be a MovingAverageType).

Motivation and Context

The interpreted exception is meant to help users fix a bad call by telling them which method's parameters didn't match. The broken parsing instead pointed at a piece of the argument list, making the guidance confusing and useless.

Requires Documentation Change

No.

How Has This Been Tested?

Added two tests to NoMethodMatchPythonExceptionInterpreterTests:

• VerifyMessageContainsTheMethodName — using the existing set_cash('SPY') reproduction, asserts the interpreted message contains SetCash and not the ">)" argument-list fragment.
• VerifyMessageContainsTheMethodNameForOverloadedMethod — reproduces the reported scenario via a new no_method_match_rsi method (self.rsi(symbol, 15, Resolution.DAILY)) and asserts the message contains RSI and not ">)".

Both tests fail before the fix and pass after. The full NoMethodMatchPythonExceptionInterpreterTests fixture passes (13/13).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

[Martin-Molinero]

Nice!