-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
assertRaises as a context manager should accept a 'msg' keyword argument. #54984
Comments
assertRaises used as a method can't take a msg keyword argument because all args and keywords are passed to the callable. But in context manager form it could, and this can be useful. See, for example, bpo-3583. |
I'm fine with this functionality being added in 3.3. |
I decided to try my hand at writing a patch for python. I ended up implementing the behavior for assertRaises, assertRaisesRegex, assertWarns, and assertWarnsRegex. I also made those functions complain about other arguments rather then just ignoring them. |
Changing callableObj to callable_obj in assertRaises will break for anyone that's upgrading to 3.3. I left a comment on the review. |
Aren't such use cases already covered by assertRaisesRegex? |
How does assertRaisesRegex address the use case in bpo-3583? |
robquad mentions having left a comment on the review, but I'm not seeing how to view it. Can somebody explain? It wasn't necessary to change the callable_obj bit, but both form were being used so I thought it best to standardize. Neither version of the parameter name shows up in the documentation. |
Michael pointed out that I had completely missed the point of what the "msg" argument was about. Sorry for the noise. |
|
I showed robquad how to do the review stuff at PyCon but I forgot about the publish part. Robbie, if you hit "Publish + Mail Comments" near the top of the page after you've left comments, it'll send them out. What he noticed was that changing to callable_obj in the assertRaises signature could break anyone who had been using callableObj as a named argument. Although it isn't explicitly documented, it's a named argument that someone is probably using. As for standardizing, it's probably best to match the general format of the library which is camelCase, and change the internal uses rather than a public method signature. |
The public methods were using both callable_obj and callableObj. Perhaps the patch should standardize on callableObj and accept callable_obj with a warning? |
Attached a revised patch. |
New patch by Ezio looks good to me. Go ahead and commit. Please raise a separate issue for error reporting when invalid argument combinations are used. (i.e. additional keyword arguments but no callable.) |
New changeset 8fc801ca9ea1 by Ezio Melotti in branch 'default': |
Done, thanks for the patch! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: