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.)

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.

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?

@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.

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

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.

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.

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.

based on the reaction from those who own mock at this point, i'm going to close this.  shipping more handy mock matchers with mock makes sense to me as they belong together.  but i'm not willing to argue it if anyone thinks it'll be a maintenance burden within the stdlib.