[issue35753] Importing call from unittest.mock directly causes ValueError
David Antonini added the comment:
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
--
___
Python tracker
<https://bugs.python.org/issue35753>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35753] Importing call from unittest.mock directly causes ValueError
New submission from David Antonini :
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.
--
components: Tests
messages: 333786
nosy: toonarmycaptain
priority: normal
severity: normal
status: open
title: Importing call from unittest.mock directly causes ValueError
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35753>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35753] Importing call from unittest.mock directly causes ValueError
David Antonini added the comment:
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.
--
___
Python tracker
<https://bugs.python.org/issue35753>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35753] Importing call from unittest.mock directly causes ValueError
David Antonini added the comment: Apologies for initial malformed message, I hit submit prematurely. -- ___ Python tracker <https://bugs.python.org/issue35753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31873] Inconsistent capitalization of proper noun - Unicode.
New submission from David Antonini : Make 'unicode'/'Unicode' capitalization consistent. 'Unicode' is a proper noun, and as such should be capitalized. I submitted a pull request correcting the inconsistent capitalization in the Unicode page of the Documentation - Doc/c-api/unicode.rst - capitalizing 12 errant instances to reflect the correct capitalization in most of the document. I was then requested to open an issue here for discussion. -- assignee: docs@python components: Documentation messages: 305050 nosy: docs@python, toonarmycaptain priority: normal pull_requests: 4096 severity: normal status: open title: Inconsistent capitalization of proper noun - Unicode. type: enhancement ___ Python tracker <https://bugs.python.org/issue31873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31873] Inconsistent capitalization of proper noun - Unicode.
David Antonini added the comment: Does the Unicode documentation currently conform to that convention, or does it require editing? It appears to me that a lot of cases where reference to "Unicode object" is currently capitalised (most of them, in fact) may need to be modified. However, it would seem that there is a grey area in making a distinction between reference to the unicode type as implemented in Python and reference to the standard as a descriptor of the format of an object? The way I read there a lot of the cases are in essence a reference to both. -- ___ Python tracker <https://bugs.python.org/issue31873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
