Stefan Behnel <stefan...@behnel.de> added the comment:
The problem in the test added in PR 21473 is that there is an intermediate base type "object" in the hierarchy: class A(type): def __setattr__(cls, key, value): type.__setattr__(cls, key, value) class B: pass class C(B, A): pass >>> [c for c in C.__mro__] [<class '__main__.C'>, <class '__main__.B'>, <class '__main__.A'>, <class 'type'>, <class 'object'>] >>> [c.__setattr__ for c in C.__mro__] [<function A.__setattr__ at 0x7f3ca4308378>, <slot wrapper '__setattr__' of 'object' objects>, <function A.__setattr__ at 0x7f3ca4308378>, <slot wrapper '__setattr__' of 'type' objects>, <slot wrapper '__setattr__' of 'object' objects>] I think the change to the algorithm there is too broad, it disables much of what the check was written for (or against). Given Guido's second (negative) test case, I think it would also not be correct to add "object.__setattr__" to the list of allowed (intermediate) slot methods: class A(type): def __setattr__(cls, key, value): object.__setattr__(cls, key, value) # this should fail! class B: pass class C(B, A): pass It's difficult to turn this into an algorithm. Is the MRO really the place to look? For "A", we're only really interested in the C-level bases, aren't we? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39960> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com