Stefan Behnel <[email protected]> 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 <[email protected]>
<https://bugs.python.org/issue39960>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
