Add DLR get/set support (IDynamicMetaObjectProvider) - #123
Add DLR get/set support (IDynamicMetaObjectProvider)#123Martin-Molinero wants to merge 4 commits into
Conversation
Sorry, something went wrong.
(cherry picked from commit 5dacfb4)
- Catch exceptions in TrySet/DeleteMember - Convert the exceptions into Python exceptions - Add tests for the remaining cases - Add a note on why the field has to be lazily initialized (general issue with derived classes) (cherry picked from commit 2408c43)
…onnet#2718) The dynamic getter swallowed any exception from TryGetMember and returned default to Python with the prior AttributeError still set, so user code observed a misleading AttributeError instead of the real failure. Set a Python exception in the catch arm. We use RuntimeError with the message string rather than Converter.ToPython(e) because wrapping the CLR exception object can trigger type initialisation that re-enters this same slot on the live dynamic object, producing infinite recursion. Mirrors the symmetry already present in the setter (pythonnet#2706 review, @lostmsu) and adds a regression test alongside the existing ThrowingSetDynamicObject coverage. (cherry picked from commit 8b12b56)
- Cache HasClrMember reflection per (Type, name) so tp_getattro_dlr_proxy / tp_setattro_dlr_proxy avoid repeated GetMember() calls on every attribute access of DLR-aware objects. - Mirror tp_setattro_dlr_proxy's catch arm to the getter's safer SetError(RuntimeError, e.Message) shape instead of SetError(Exception), keeping both slots re-entry-safe on live dynamic objects. Related to pythonnet#2706. (cherry picked from commit 3a08990)
|
CI status: builds clean, but the DLR feature's own embed tests fail on all Python versions (e.g. TestSetPublicDynamicObjectPropertyWorks, TestDynamicObjectCanAccessCSharpNonDynamicPropertiesAndFieldsWithPEP8Syntax). So beyond re-enabling the mixins providers (the pythonnet#1785 revert noted above), the get/set feature doesn't function correctly against this fork's diverged attribute machinery — most likely its interaction with the fork's PEP8/snake_case member access and custom TypeManager setattr path. i.e. this isn't a clean cherry-pick — making DLR get/set work here needs real porting onto the fork's attribute handling, on top of the pythonnet#1785 mixins decision. Leaving the PR open for your call; I'd recommend treating it as a "do we want this feature enough to port it" decision rather than merging as-is. |
Sorry, something went wrong.
|
Closing for now |
Sorry, something went wrong.
Cherry-picks from upstream pythonnet/pythonnet adding DLR get/set support so .NET IDynamicMetaObjectProvider objects (e.g. dynamic/ExpandoObject) expose their dynamic members to Python. -x cherry-picked (authorship preserved: Benedikt Reinartz, @greateggsgreg).
Commits:
Builds clean (Python.Runtime.csproj + Python.EmbeddingTest.csproj).
⚠️ Decision required — this re-enables the mixins providers (reverts pythonnet#1785)
This feature is delivered through the mixins mechanism, which this fork deliberately disabled (the // see pythonnet/pythonnet#1785 comment in InteropConfiguration.cs). To make DLR get/set work I had to re-enable CollectionMixinsProvider and add DynamicObjectMixinsProvider in InteropConfiguration.cs.
That means this PR effectively reverts the pythonnet#1785 decision. Please decide whether you want the mixins providers back on — re-enabling CollectionMixinsProvider also restores the collection mixins (and the IDisposable context-manager from #119 would then work too). If pythonnet#1785 was disabled for a real reason, that reason returns with this PR. CI on this PR will show whether re-enabling mixins breaks anything in the fork's suite.
Conflict resolution: InteropConfiguration.cs (re-enabled both providers), TypeManager.cs (kept upstream's try/catch setter path). Opening for your decision as requested.
🤖 Generated with Claude Code