classification
Title: Provide additional matchers for unittest.mock
Type: enhancement Stage: patch review
Components: Tests Versions: Python 3.10
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: gregory.p.smith Nosy List: Flameeyes, cheryl.sabella, cjw296, gregory.p.smith, lisroach, mariocj89, michael.foord, python-dev, xtreak
Priority: low Keywords: patch

Created on 2020-04-01 10:00 by Flameeyes, last changed 2020-06-23 14:36 by cjw296.

Pull Requests
URL Status Linked Edit
PR 19310 closed python-dev, 2020-04-02 18:51
Messages (8)
msg365457 - (view) Author: Diego Elio Pettenò (Flameeyes) * Date: 2020-04-01 10:00
The unittest.mock `assert_called_*with*` methods take either literals, or the single `ANY` special matcher (https://docs.python.org/3/library/unittest.mock.html#any) to match any argument.

Experience suggests me that it's useful to have more flexible matchers, such as INSTANCEOF or REGEXP.

Will provide a starting pull request for this today. (Be warned: it's the first time I try contributing to CPython.)
msg366586 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2020-04-16 08:54
Thanks for the idea. But given the size of the patch and benefit it provides for the code I feel it could be a better idea to have it in PyPI and then add it to stdlib later once it gathers more feedback and adoption. Adding others for more feedback.
msg366588 - (view) Author: Chris Withers (cjw296) * (Python committer) Date: 2020-04-16 09:11
Agreed, this would be better placed in a third party library.

There's examples out there already, for example, I maintain a library [0] that has tools for asserting about complex data structures, including flexible type matching [1] and regex string matching [2].

[0] https://testfixtures.readthedocs.io/en/latest/comparing.html#the-compare-function
[1] https://testfixtures.readthedocs.io/en/latest/comparing.html#comparison-objects
[2] https://testfixtures.readthedocs.io/en/latest/comparing.html#string-comparison-objects

Diego, would you be okay if we closed this issue and the accompanying pull request?
msg369734 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2020-05-23 18:22
@Flameeyes, thank you for the suggestion.  As per the other comments, I'm going to close this as it would be more suitable to have it on PyPI.  Feel free to have more discussion here or on python-ideas if you want to get more feedback.
msg369745 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2020-05-23 19:55
I disagree.  Many of these do belong in the stdlib and we don't need a python-ideas bike shedding 300 message thread about something so trivial.

We've been using these internally at Google for years.

Its on my plate to identify which ones to accept and get the most used useful ones in.  With an additional eye to which ones we'd likely use when testing the stdlib itself.

They fit right in with https://docs.python.org/3/library/unittest.mock.html#helpers
msg371798 - (view) Author: Chris Withers (cjw296) * (Python committer) Date: 2020-06-18 09:38
Gregory, I find your response a little troubling. Myself and Karthikeyan both do a lot of work on Mock, some might even say we're the maintainers of Mock in both cpython's core repo and the backport.

We both feel this belongs standalone on pypi, and would prefer not to see this merged.

"We've been using these internally at Google for years" is not a compelling argument and suggests you already have a viable solution which doesn't involve merging these into the core repo. Your phrasing could be interpreted as somewhat bullying - "it's right for Google, so I'm going to do it for all of Python in spite of comments from other core contributors, and I don't want to discuss this on a mailing list because that will take too long".

Please consider re-closing this issue and respecting the decisions of those of us who maintain mock long-term. If not, please suggest a way forward to mediate this disagreement, but please do not unilaterally merge anything without sorting this out first.
msg371835 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2020-06-18 20:11
I suggest waiting to see what I come up with as a proposal for what part(s) of this makes sense in the stdlib and why.  I've closed the PR.

Nothing is going to be added to mock without your agreement.

This issue is not a high priority for me, but leaving it open and assigned to me as reminder helps keep the TODO of whittling the proposal down with justifications on my radar.
msg372174 - (view) Author: Chris Withers (cjw296) * (Python committer) Date: 2020-06-23 14:36
Okay, but to be up-front about this, I don't see any place in the stdlib for any more "helpers" that could more easily be maintained on pypi and wouldn't incur further support burden for anyone looking after this part of the standard library.

The only "helper" in the section you refer to is https://docs.python.org/3/library/unittest.mock.html#mock-open which I'd consider vestigal and a bit of a maintenance magnet.
History
Date User Action Args
2020-06-23 14:36:55cjw296setmessages: + msg372174
2020-06-18 20:11:07gregory.p.smithsetpriority: normal -> low

messages: + msg371835
2020-06-18 09:38:05cjw296setmessages: + msg371798
2020-05-29 23:57:16terry.reedysetstage: resolved -> patch review
2020-05-23 19:55:42gregory.p.smithsetstatus: closed -> open
versions: + Python 3.10, - Python 3.9
messages: + msg369745

assignee: gregory.p.smith
resolution: rejected ->
2020-05-23 18:22:44cheryl.sabellasetstatus: open -> closed

nosy: + cheryl.sabella
messages: + msg369734

resolution: rejected
stage: patch review -> resolved
2020-04-16 09:11:42cjw296setmessages: + msg366588
2020-04-16 08:54:44xtreaksetnosy: + cjw296, michael.foord, lisroach, mariocj89
messages: + msg366586
2020-04-02 19:02:23Flameeyessetnosy: + gregory.p.smith
2020-04-02 18:51:29python-devsetkeywords: + patch
nosy: + python-dev

pull_requests: + pull_request18673
stage: patch review
2020-04-01 11:00:01xtreaksetnosy: + xtreak
2020-04-01 10:00:05Flameeyescreate