[issue40133] Provide additional matchers for unittest.mock

Gregory P. Smith added the comment: 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

[issue40133] Provide additional matchers for unittest.mock

Chris Withers added the comment: 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

[issue40133] Provide additional matchers for unittest.mock

Gregory P. Smith added the comment: 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

[issue40133] Provide additional matchers for unittest.mock

Chris Withers added the comment: 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

[issue40133] Provide additional matchers for unittest.mock

Change by Terry J. Reedy : -- stage: resolved -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40133] Provide additional matchers for unittest.mock

Gregory P. Smith added the comment: 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

[issue40133] Provide additional matchers for unittest.mock

Cheryl Sabella added the comment: @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. -- nosy:

[issue40133] Provide additional matchers for unittest.mock

Chris Withers added the comment: 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

[issue40133] Provide additional matchers for unittest.mock

Karthikeyan Singaravelan added the comment: 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

[issue40133] Provide additional matchers for unittest.mock

Change by Diego Elio Pettenò : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40133] Provide additional matchers for unittest.mock

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 2.0 -> 3.0 pull_requests: +18673 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19310 ___ Python tracker

[issue40133] Provide additional matchers for unittest.mock

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40133] Provide additional matchers for unittest.mock

New submission from Diego Elio Pettenò : 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