[issue20968] mock.MagicMock does not mock __truediv__
New submission from Johannes Baiter: It seems that when creating a MagicMock the magic '__truediv__' method is not replaced with a mock: >>> import mock >>> foo = mock.MagicMock() >>> foo / 2 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for /: 'MagicMock' and 'int' The same thing works perfectly fine when using the third party module in Python 2.7, since the 2.x '__div__' seems to be mocked: >>> import mock >>> foo = mock.MagicMock() >>> foo/2 To clarify the context, I am trying to mock a 'pathlib.Path' object in my unittest, which overloads the division operator, i.e. implements '__truediv__'. -- components: Library (Lib) messages: 213964 nosy: Johannes.Baiter priority: normal severity: normal status: open title: mock.MagicMock does not mock __truediv__ type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue20968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20968] mock.MagicMock does not mock __truediv__
Johannes Baiter added the comment: Attached is a patch that fixes the issue for me. -- keywords: +patch Added file: http://bugs.python.org/file34490/mock_truediv.diff ___ Python tracker <http://bugs.python.org/issue20968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20968] mock.MagicMock does not mock __truediv__
Johannes Baiter added the comment: I just noticed that I put the magic method names in the wrong place in the patch. Attached is a fix that adds 'truediv' to the global 'numberics' variable, this way '__rtruediv__' and '__itruediv__' will be correctly mocked as well. -- Added file: http://bugs.python.org/file34491/mock_truediv_numerics.diff ___ Python tracker <http://bugs.python.org/issue20968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20968] mock.MagicMock does not mock __truediv__
Johannes Baiter added the comment: >From looking at 'test_numerics', only 'add' is currently tested. Probably since the mechanism for all of the numeric magic methods is the same (i.e. create , __i__, __r__). Should I add a test for __truediv__ and its inplace and right variants nonetheless? -- ___ Python tracker <http://bugs.python.org/issue20968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20968] mock.MagicMock does not mock __truediv__
Changes by Johannes Baiter : Added file: http://bugs.python.org/file34515/mock_truediv_with_tests.diff ___ Python tracker <http://bugs.python.org/issue20968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20968] mock.MagicMock does not mock __truediv__
Johannes Baiter added the comment: Sorry for commenting so late, I submitted a version of the patch with unit tests roughly two weeks ago, I just forgot to mention it in a comment. Hereby fixed :-) -- ___ Python tracker <http://bugs.python.org/issue20968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21345] multiprocessing.Pool._handle_workers sleeps too long
New submission from Johannes Baiter:
While testing a module that uses multiprocessing.Pool to distribute load across
multiple processes, I noticed that my test suite was copmleting very quickly
(~0.15s) on Python 2.6, while Python 2.7 and above took around 10x as long
(~1.6s).
Upon debugging this, I pinned the slowdown down to the 'Pool.join()' method.
Removing it removed the slowdown almost completely.
I then checked the version history of the 'multiprocessing.pool' module between
2.6 and 2.7 and noticed that when the 'maxtasksperchild' parameter was
introduced, a thread to handle the workers was introduced, which was 'join()'ed
when the pool was joined.
This is the function that is executed in the thread (from latest CPython
checkout):
@staticmethod
def _handle_workers(pool):
thread = threading.current_thread()
# Keep maintaining workers until the cache gets drained, unless the pool
# is terminated.
while thread._state == RUN or (pool._cache and thread._state !=
TERMINATE):
pool._maintain_pool()
time.sleep(0.1) # <-- Cause of slow 'join()' after 2.6
# send sentinel to stop workers
pool._taskqueue.put(None)
util.debug('worker handler exiting')
I highlighted the portion that makes 'join()' take a rather long time with
short-lived processes in Python 2.7 and greater.
Replacing it with 'time.sleep(0)' (as is done in '_help_stuff_finish()' later
in the module) makes joining go as fast as in 2.6.
Is there a specific reason why this sleep period was chosen?
--
components: Library (Lib)
messages: 217129
nosy: Johannes.Baiter
priority: normal
severity: normal
status: open
title: multiprocessing.Pool._handle_workers sleeps too long
type: performance
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue21345>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
