GeezerVison

__getattribute__ and __getattr__ share the getattro slot. When one of them was removed from a class, the slot update re-inherited from the first base with a getattro slot. It never looked at a __getattribute__ in the class's own dict, so a subclass's override was silently lost. This is what happens to subclasses after mock.patch.object(Base, "__getattr__", ..., create=True) exits.

class Base: pass
class Proxy(Base):
    def __getattribute__(self, name):
        print("Proxy.__getattribute__", name)
        return object.__getattribute__(self, name)

p = Proxy(); p.x = 1
Base.__getattr__ = lambda self, name: "fallback"
del Base.__getattr__
p.x  # CPython: calls Proxy.__getattribute__; RustPython (before): skipped it

Changes

• crates/vm/src/types/slot.rs (SlotAccessor::TpGetattro): when no __getattr__ is in the MRO, always resolve the slot through lookup_slot_in_mro on __getattribute__, for both add and remove. Previously this happened only on add, and it used the changed name rather than __getattribute__. The inherit_from_mro fallback on removal is gone, so this now matches how TpSetattro resolves __setattr__/__delattr__.
• extra_tests/snippets/builtin_object.py: regression test for the add-then-delete sequence above.

• Fixes Deleting __getattr__ from a base class stops a subclass's own __getattribute__ from being called #9796