Bug report

Bug description:

this is an entirely silly example boiled down from a much more complex one to demonstrate the behaviour. the actual code here is nonsensical (Test2 will always fail) but Test1 should work just fine -- the decoration of the subclass Test2 seems to also decorate Test1's methods unexpectedly

from unittest import mock

s = 0

@mock.patch(f"{__name__}.s", 5)
class Test1:
    def test_1(self):
        assert s == 5, s


@mock.patch(f"{__name__}.s", 2)
class Test2(Test1): pass

Test1().test_1()

$ python3.12 t2.py
Traceback (most recent call last):
  File "/Users/asottile/workspace/sentry/t2.py", line 14, in <module>
    Test1().test_1()
  File "/opt/homebrew/Cellar/python@3.12/3.12.2_1/Frameworks/Python.framework/Versions/3.12/lib/python3.12/unittest/mock.py", line 1387, in patched
    return func(*newargs, **newkeywargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/asottile/workspace/sentry/t2.py", line 8, in test_1
    assert s == 5, s
AssertionError: 2

the problem appears to be here:

whereas I think it should always return a new callable instead of mutating a potentially unrelated method

CPython versions tested on:

3.12

Operating systems tested on:

macOS

Linked PRs

• gh-117507: avoid patch as a class decorator to mutate an inherited method #117665
• gh-117507: avoid patch as a class decorator to mutate an inherited method #117667
• gh-117507: avoid mock.patch as a class decorator to mutate an inherited method #117687