Ok so that's a pretty odd bug. I already had from unittest.mock import patch, mock_open so I simply modified that to from  instead of doing mock.call in my test. Changing this to from unittest import mock and then mock.call fixed the error.

from unittest.mock import patch, mock_open, call

mocked_print.assert_has_calls([
    call("first print"),
    call("second print"),
    ])

I get: 

C:\Program Files (x86)\Python37-64\lib\doctest.py:932: in find
    self._find(tests, obj, name, module, source_lines, globs, {})
C:\Program Files (x86)\Python37-64\lib\doctest.py:991: in _find
    if ((inspect.isroutine(inspect.unwrap(val))
C:\Program Files (x86)\Python37-64\lib\inspect.py:515: in unwrap
    raise ValueError('wrapper loop when unwrapping {!r}'.format(f))
E   ValueError: wrapper loop when unwrapping call
collected 1 item / 1 errors

But when I don't import call directly my test runs as expected:

from unittest.mock import patch, mock_open

import unittest.mock

mocked_print.assert_has_calls([
    mock.call(),
    mock.call(),
    ])

I have the same issue when using:

assert mocked_print.call_args_list == [call("first print"), call("second print")] <- ValueError
assert mocked_print.call_args_list == [mock.call("first print"), mock.call("second print")] <- Works as expected.

I'm having a problem with mock.call when I import it directly from unittest.mock.

When I do:

from unittest.mock import patch, mock_open, call

mocked_print.assert_has_calls([
    call("first print"),
    call("second print"),
    ])

I get: 

C:\Program Files (x86)\Python37-64\lib\doctest.py:932: in find
    self._find(tests, obj, name, module, source_lines, globs, {})
C:\Program Files (x86)\Python37-64\lib\doctest.py:991: in _find
    if ((inspect.isroutine(inspect.unwrap(val))
C:\Program Files (x86)\Python37-64\lib\inspect.py:515: in unwrap
    raise ValueError('wrapper loop when unwrapping {!r}'.format(f))
E   ValueError: wrapper loop when unwrapping call
collected 1 item / 1 errors

But when I don't import call directly my test runs as expected:

from unittest.mock import patch, mock_open

import unittest.mock

mocked_print.assert_has_calls([
    mock.call(),
    mock.call(),
    ])

I have the same issue when using:

assert mocked_print.call_args_list == [call("first print"), call("second print")] <- ValueError
assert mocked_print.call_args_list == [mock.call("first print"), mock.call("second print")] <- Works as expected.

Apologies for initial malformed message, I hit submit prematurely.

Hi David,

Can you provide a full reproducer? In your example, mocked_print is undefined. Please, provide a self-contained script that can be executed to test the behaviour.

According to the error message, this is a duplicate of https://bugs.python.org/issue25532

Indeed, closed as duplicate of https://bugs.python.org/issue25532

Sorry, looks like I was wrong about it being a duplicate. The actual bug appears to be "doctest can't run on a module that contains un-unwrappable objects", which there probably is an issue for but I don't know what it is.

I think this tickt needs to be reopened, because

> The actual bug appears to be "doctest can't run on a module that contains un-unwrappable objects"

@ppperry Or do you already know where this issue is tracked?

Indeed, you are right that this should be reopened.

> The actual bug appears to be "doctest can't run on a module that contains un-unwrappable objects"

Is it the below example scenario being discussed in the issue? Since call is imported it's also present in obj.__dict__ and hence trying to unwrap it [0] could cause error.

This is also mentioned in https://bugs.python.org/issue25532#msg253885 against which this issue was closed. 

> This can occur when you use doctest.DocTestSuite to load doc tests from a module where unittest.mock.call has been imported.

# bpo35753.py
from unittest.mock import call

./python.exe -m doctest bpo35753.py
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 2785, in <module>
    sys.exit(_test())
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 2775, in _test
    failures, _ = testmod(m, verbose=verbose, optionflags=options)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 1947, in testmod
    for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 932, in find
    self._find(tests, obj, name, module, source_lines, globs, {})
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 991, in _find
    if ((inspect.isroutine(inspect.unwrap(val))
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/inspect.py", line 524, in unwrap
    raise ValueError('wrapper loop when unwrapping {!r}'.format(f))
ValueError: wrapper loop when unwrapping call


[0] https://github.com/python/cpython/blob/aaf47caf35984e614d93bd8bea5227df55e0e3e6/Lib/doctest.py#L991

Somehow I missed the follow up here until now. I don't remember the original code, but I'm fairly confident that mocked_print is the patched print function eg 
with patch('dionysus_app.class_functions.print') as mocked_print:

Probably solved in this commit dated the same day as the bug report:
https://github.com/toonarmycaptain/dionysus/commit/4f0eb7ca32b891d99106441b92a6c1accd0bb96d

I have a patch here that fixes this: https://github.com/python/cpython/pull/22981

It simply swallows the unwrap exception making doctest immune to such buggy objects.

Can someone help it get reviewed please?

New changeset 10d6f6bfd749c0e7da51a96f53ca326c336f7a00 by Miss Islington (bot) in branch '3.10':
bpo-35753: Fix crash in doctest with unwrap-able functions (GH-22981) (#25926)
https://github.com/python/cpython/commit/10d6f6bfd749c0e7da51a96f53ca326c336f7a00

Fixed in 3.10 and 3.11, thanks Albert for your patch.