fix(monkeypatch): don't leave inherited attributes in the instance dict

[Irahan2]

Closes #10644.

Problem

MonkeyPatch.setattr() records the old value with getattr(), which follows the MRO. When the patched attribute is inherited rather than owned by the instance, undo() assigns that inherited value back onto the instance, creating a __dict__ entry that was never there:

class Parent:
    x = 1

class Child(Parent):
    pass

obj = Child()
mp.setattr(obj, "x", 2)
mp.undo()
assert "x" not in vars(obj)   # fails on main: vars(obj) == {"x": 1}

For a plain class attribute this only leaves the target in a different state than it was found in. For an inherited non-data descriptor it is worse: the value computed during teardown is stored on the instance and shadows the descriptor, so the attribute is frozen for every later lookup.

class Dynamic:
    def __init__(self):
        self.calls = 0

    def __get__(self, instance, owner=None):
        self.calls += 1
        return self.calls

class Sample:
    value = Dynamic()

obj = Sample()
obj.value, obj.value      # 1, 2 -- resolves dynamically
mp.setattr(obj, "value", "patched")
mp.undo()
obj.value, obj.value      # 3, 3 -- frozen from here on, on main

Patching a method on an instance hits the same path, leaving a bound method behind in vars(obj) after teardown.

Fix

Look the old value up in the instance __dict__ — which is what setattr() and undo() actually operate on — mirroring the handling setattr() already has for classes.

The lookup is guarded by a data-descriptor check, and that guard is load-bearing. A data descriptor intercepts the assignment, so the attribute never reaches the instance __dict__ and there is nothing there to delete on undo. Without the guard, monkeypatch.setattr() on a property fails during undo with AttributeError: property 'x' of 'Sample' object has no deleter, and __slots__ attributes break the same way. test_undo_data_descriptor_on_instance and test_undo_slot_attribute_on_instance cover both.

Notes

Only setattr() is changed. delattr() has the same shape but cannot reach this state: deleting an inherited attribute from an instance raises AttributeError, so nothing is recorded. Its separate undo-ordering issue is #14909.

Verified locally on Python 3.13 (Windows): the three new tests reproducing the bug fail without the change and pass with it, and the full test suite is unaffected.

Checklist

• Include new tests or update existing tests when applicable.
• Add text like closes #XYZW to the PR description and/or commits.
• Create a new changelog file in the changelog directory.
• Add yourself to AUTHORS in alphabetical order.
• Allow maintainers to push and squash when merging my commits.

AI/LLM assistance

Per the AI/LLM-Assisted Contributions Policy: this change was developed with AI assistance (Claude Code), credited in the Co-authored-by trailer on the commit. Happy to explain any part of it or adjust the approach.

[Shriprasad-P]

The inherited-attribute fix itself looks correct for normal instance storage and descriptor behavior, but I found a regression for objects with custom attribute assignment.

The new branch assumes that, when no data descriptor exists, setattr(target, name, value) writes into target.__dict__. That is not always true because a class can override __setattr__ and store attributes elsewhere.

For example, with an object that keeps values in a backing _store through __getattr__ / __setattr__, the current implementation works on base: monkeypatch records the resolved old value and undo restores _store["x"] to that value.

On this PR, x is absent from target.__dict__, so oldval becomes NOTSET. Undo then calls delattr(target, "x"), which can raise AttributeError or remove the proxy-backed value rather than restoring the original state.

Please preserve resolved-value restoration for targets with custom assignment machinery, or otherwise make the snapshot/undo strategy account for custom __setattr__ behavior, and add a regression test for that case.

The normal inherited attribute, non-data descriptor, method, property, slot, and direct-instance cases otherwise look correct.