Not one, dear reader, not two, but three pull requests were submitted today. What a rush.
What I did
I hadn’t had any comments on my patch that I posted to the bpo thread last week, so I went ahead and submitted a pull request. I think this was the right thing to do, and hopefully it’ll get a review before my next day of
MagicMock and divmod
My winners of the options from last time were
Return a pair of
MagicMockinstances. This is very sensible and in-keeping with the rest of the behaviour of
Change the behaviour of
MagicMockmore generally such that trying to unpack a
MagicMockinstance into two variables, for example, would assign a new
MagicMockinstance to each. This would be a bit more far-reaching than this issue but might be worth thinking about. This would fix the issue as a side-effect, as the current result of e.g.
divmod(MagicMock(), 2)is another instance of
I posted as such on the bpo thread and was informed that the second option was a bit ambitious - there’s no implementation-agnostic way for
MagicMock to “know” how many variables it’s being unpacked into.
I therefore decided to plump for the first option and looked through
unittest.mock to find the right place to add this functionality - I ended up taking a bit of a scenic route but got there in the end. The solution that I went for was to add
__divmod__’s right-hand cousin) to the list of side-effect methods, which includes methods such as
__iter__ which have a default behaviour within
m.__eq__(other) checks by default for object identity: if
other are names for the same object. Adding
__rdivmod__ was simply a matter of defining some new default behaviour - return a pair of
MagicMock instances. This now means that
MagicMock behaves as
>>> from unittest.mock import * >>> floordiv, mod = divmod(MagicMock(), 2) >>> print(floordiv, mod) <MagicMock id='139748283461136'> <MagicMock id='139748283411024'> >>> floordiv, mod = divmod(2, MagicMock()) >>> print(floordiv, mod) <MagicMock id='139748278535024'> <MagicMock id='139748278597184'> >>> floordiv, mod = divmod(MagicMock(), MagicMock()) >>> print(floordiv, mod) <MagicMock id='139748278678624'> <MagicMock id='139748278741744'>
A few updates to the
unittest.mock tests later, I was able to confirm that I hadn’t broken anything and raise a pull request. I haven’t had any activity on this yet but will hopefully do so at some point.
Removing asyncore from tests
asyncore was one of the modules used in Python to implement asynchronous behaviour before
asyncio came along, and has been deprecated since Python 3.6, but is still used in some tests. Issue 28533 covers removing these mentions and reimplementing the internals of a handful of test files using
This issue was recommended to be broken into subissues for each test file in question, so spotting a trivial one I could get done before heading home, I raised Issue 38866 and removed a mention from the
pyclbr test file. Third PR raised, and it’s since been reviewed! I’ll probably work on some other test files next time.
I think my third day of contribution went pretty well, it felt great to get some PRs raised - hopefully these don’t end up blocked on review. I think I’ll keep looking out for issues to work on before next time, because I spent a non-zero percentage of the day looking for issues, which is not the most efficient use of time. Still enjoying and feeling good about everything!