This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: assertWarnsRegex doesn't allow multiple warning messages
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.6
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, ezio.melotti, michael.foord, rbcollins, serhiy.storchaka, sleepycal, superluser
Priority: normal Keywords:

Created on 2015-08-24 14:15 by sleepycal, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (5)
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) * (Python committer) 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) * (Python committer) 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: 'msg1|msg2'.

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) * (Python committer) Date: 2016-04-16 18:25
Agreed. Let's close this then.
History
Date User Action Args
2022-04-11 14:58:20adminsetgithub: 69110
2016-04-16 18:25:35berker.peksagsetstatus: open -> closed

nosy: + berker.peksag
messages: + msg263574

resolution: rejected
stage: needs patch -> resolved
2016-04-16 18:03:13serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg263571
2016-04-16 16:41:35berker.peksagsettype: behavior -> enhancement
components: + Library (Lib), - Interpreter Core
versions: - Python 3.5
2016-03-14 03:04:03rbcollinssetmessages: + msg261718
2016-01-18 22:58:18superlusersetnosy: + superluser
messages: + msg258558
2016-01-04 00:16:40ezio.melottisetnosy: + rbcollins, ezio.melotti, michael.foord
stage: needs patch

versions: + Python 3.5, Python 3.6, - Python 3.4
2015-08-24 14:15:48sleepycalcreate