| msg249048 - (view) |
Author: Cal Leeming (sleepycal) |
Date: 2015-08-24 14:15 |
| There was a discussion/patch in #9754 [1]. This allows for multiple warning types as a tuple, e.g.; self.assertWarnsRegex((DeprecationWarning, RuntimeWarning), "^E1000:") However, it does not allow testing for multiple warning messages, e.g.; expect = ((UserWarning, "^W1000"), (UserWarning, "^W1001")) self.assertWarnsRegex(*expect) This is slightly unexpected, as `test.support.check_warnings` allows this behaviour, e.g. expect = ((UserWarning, "^W1000"), (UserWarning, "^W1001")) check_warnings(*expect) Therefore I am proposing that `assertWarnsRegex` and `assertWarns` are modified to reflect the behaviour of `check_warnings`, whilst ensuring backwards compatibility. (e.g. if arg[0] is tuple, use new approach, otherwise use old approach). [1]: http://bugs.python.org/issue9754 |
|
|
| msg258558 - (view) |
Author: Rose Ames (superluser) * |
Date: 2016-01-18 22:58 |
| Would this mean that we expect any one of the warnings to be raised, or all of them? If it's one, the example you give would be equivalent to: self.assertWarnsRegex(UserWarning, "^W100[01]") Matching all of the warnings seems more interesting, but I'm not sure how to handle the context manager attributes. For instance, right now you can do: with self.assertWarnsRegex(FooWarning, "Bar") as cm: blah() self.assertEquals(cm.lineno, 1000) Would lineno and filename become lists? It seems kind of ugly. What's the advantage over simply testing for each warning separately? |
|
|
| msg261718 - (view) |
Author: Robert Collins (rbcollins) *  |
Date: 2016-03-14 03:04 |
| The context manager errors if *nothing* matches, not if *everything* matches, which is very different to catch_warnings because the filters are used to *exclude* warnings, and excess warnings are errors there. Because of that, there's little if any reason to add support for multiple regexes - just nest two context managers. That said... The lineno is already not-fully-informative - its the first matching warnings lineno. Right now, the definition in the code is: for warnings in (the warning item-or-tuple) if the regex matches, done if none of the warnings match, error. If we allow the tuple of warnings to be a tuple of (warning, regex) items, we could do that compatibly, with some introspection. If the patch is fairly small, It might be ok, for all that I don't see a need for it. |
|
|
| msg263571 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2016-04-16 18:03 |
| I think there is a little need for this feature. On other hand, its use looks complicated, and it will likely complicate the implementation. If tested types are same, but messages differ, messages can be combined in on regex: '|'. If tested types differ, but messages are same, this case is already supported. If tested types and messages differ, you can test with combined regex, and then check a context manager object that the message matches the type. But this is very rare case. |
|
|
| msg263574 - (view) |
Author: Berker Peksag (berker.peksag) * |
Date: 2016-04-16 18:25 |
| Agreed. Let's close this then. |
|
|