Skip to content

mock.patch(..., autospec=True) on a functools.partialmethod attribute produces a completely uncallable mock #153581

Open

Description

@claudiubelu

Bug report

Bug description:

Autospeccing a class attribute that is a functools.partialmethod (either via mock.patch.object(cls, name, autospec=True) or mock.create_autospec(cls, ...) combined with a direct
mock.patch.object on that one attribute) produces a unittest.mock.NonCallableMagicMock. Calling it then raises TypeError: 'NonCallableMagicMock' object is not callable, even though the real attribute is perfectly callable (instance.method(...) works fine on the un-mocked class).

import functools
from unittest import mock

class Client:
    def _send_request(self, method, url):
        return method, url

    _send_post_request = functools.partialmethod(_send_request, "POST")

with mock.patch.object(Client, "_send_post_request", autospec=True) as m:
    print(type(m))  # <class 'unittest.mock.NonCallableMagicMock'>
    client = Client()
    client._send_post_request("https://example.com")
    # TypeError: 'NonCallableMagicMock' object is not callable

Root cause:

_patch.get_original() (Lib/unittest/mock.py) reads the attribute via target.__dict__[name] first, deliberately bypassing the descriptor protocol (this is needed to support patching descriptors like @property correctly). For a functools.partialmethod attribute, this yields the
raw partialmethod instance rather than the bound-callable object that getattr(instance, name) would produce.

functools.partialmethod objects are not themselves callable (they have no __call__; only __get__, since they are non-data descriptors meant to be resolved through attribute access):

>>> import functools, inspect
>>> p = functools.partialmethod(lambda self, a: None, 1)
>>> callable(p)
False
>>> inspect.signature(p)
Traceback (most recent call last):
  ...
TypeError: functools.partialmethod(<function <lambda> at 0x...>, 1, ) is not a callable object

CPython versions tested on:

3.12, but tested on main as well.

Operating systems tested on:

Linux

Linked PRs

Activity

  1. flameastro commented on Jul 11, 2026

    @flameastro
  2. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Jul 12, 2026
  3. added a commit that references this issue on Jul 12, 2026
  4. added 2 commits that reference this issue on Sep 21, 2026
  5. added 2 commits that reference this issue on Oct 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions