Skip to content

Add DLR get/set support (IDynamicMetaObjectProvider)#123

Open
Martin-Molinero wants to merge 4 commits into
masterfrom
cherry/dlr-get-set-support
Open

Add DLR get/set support (IDynamicMetaObjectProvider)#123
Martin-Molinero wants to merge 4 commits into
masterfrom
cherry/dlr-get-set-support

Conversation

@Martin-Molinero

Copy link
Copy Markdown
Member

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

filmor and others added 4 commits June 19, 2026 12:55
(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)
@Martin-Molinero

Copy link
Copy Markdown
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants