Julien Palard added the comment: I found a way to fix it, but as I'm just discovering cpython internals, I'm not sure it's the right way, review are very welcome.
I fixed it this way because: The bytecode generated for "proxy.x = 0" (a STORE_ATTR) will call a PyObject_SetAttr with FooProxy which will soon execute the __setattr__ of Meta, itself calling a PyObject_SetAttr with Foo. The actual attribute setting is done from the PyObject_SetAttr with Foo (calling in turn type_setattro, and so on), but it's already too late to invalidate the FooProxy type: we no longer have a reference on it and can't guess that FooProxy delegated __setattr__ to Foo. So the only place when we can invalidate correctly is in the first call of PyObject_SetAttr when we know on which type the attribute will be set, and it make sense: It does not matter what a __setattr__ does and how it does it: invalidation should happen for this attribute on the current type, so invalidating here seems logic. I did not yet took the time to measure performance loss induced with this patch. With the patch: ./python -i weird.py >>> proxy.x 0 >>> proxy.x 0 ---------- keywords: +patch Added file: http://bugs.python.org/file45766/issue28866.diff _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28866> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
