Raise a proper TypeError when a property assignment cannot be performed#141
Open
jhonabreul wants to merge 2 commits into
Open
Raise a proper TypeError when a property assignment cannot be performed#141jhonabreul wants to merge 2 commits into
jhonabreul wants to merge 2 commits into
Conversation
d8e51db to
f039e68
Compare
Converter.ToManagedValue had three exits that reported failure without
setting a Python error: the final fall-through when a plain Python object
has no conversion to the target CLR class, the ClassBase exit when a
reflected class object is converted to something other than Type, and the
exit for managed values that are neither CLRObject, ClassBase, nor
MethodBinding (e.g. a MethodObject). Callers that pass setError true, such
as PropertyObject.tp_descr_set, trust the failure to carry a pending error
and return -1, so CPython raised "SystemError: error return without
exception set" instead of a useful message. Assigning a pure Python object
to a C# property of a CLR class type reproduced this. These exits now set
the conventional TypeError ("'<type>' value cannot be converted to
<target>") when setError is true and no more specific error is already
pending from a probing sub-path; setError false behavior is unchanged.
f039e68 to
f069ab4
Compare
11 tasks
Bump package <Version>, AssemblyVersion/AssemblyFileVersion and the perf-test baseline reference to 2.0.64.
c651aee to
760e346
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this implement/fix?
Fixes a property-assignment bug that surfaced when a Lean Python algorithm assigned a pure-Python object to
self.universe_manager(which snake-cases ontoQCAlgorithm.UniverseManager { get; private set; }) and got the opaqueSystemError: error return without exception setinstead of an actionable error:Converter.ToManagedValuecould fail without setting a Python error even when called withsetError: true. Three exits returnedfalsesilently: the final fall-through (plain Python object with no conversion to an arbitrary CLR class), the reflected-class-object case (converting a CLR class object to something other thanType), and non-MethodBindingmanaged types (method/module objects).PropertyObject.tp_descr_settrustssetError: trueand returns-1, so CPython's release-build eval loop raisesSystemError: error return without exception setat the assignment. These exits now set the same'{type}' value cannot be converted to {obType}TypeError thetype_errorlabel already uses, preserving any more specific error a probing sub-path (e.g. a throwing implicit operator) left pending.With the fix, the Lean repro turns from
SystemError: error return without exception setintoTypeError: 'UniverseManager' value cannot be converted to QuantConnect.Securities.UniverseManager, pointing straight at the offending assignment.The fix carries its own regression tests, verified red before the fix and green after.
Does this close any currently open issues?
No open issue; root-caused from a Lean user report of
error return without exception setduring algorithm initialization.Any other comments?
Python assignment to CLR properties with private setters (via reflection) is intentionally left untouched by this PR.
End-to-end verification against Lean master (the original repro):
self.universe_manager = <pure python object>in a Python algorithm now fails with a clear TypeError at the offending line instead ofSystemError: error return without exception set.