Author scoder
Recipients David Caro, Matthias Braun, gvanrossum, miss-islington, petr.viktorin, scoder
Date 2020-07-18.06:39:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1595054382.5.0.747514845101.issue39960@roundup.psfhosted.org>
In-reply-to
Content
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?
History
Date User Action Args
2020-07-18 06:39:42scodersetrecipients: + scoder, gvanrossum, petr.viktorin, miss-islington, Matthias Braun, David Caro
2020-07-18 06:39:42scodersetmessageid: <1595054382.5.0.747514845101.issue39960@roundup.psfhosted.org>
2020-07-18 06:39:42scoderlinkissue39960 messages
2020-07-18 06:39:42scodercreate