assertWarnsRegex doesn't allow multiple warning messages

[sleepycal]

BPO	24922
Nosy	@rbtcollins, @ezio-melotti, @voidspace, @berkerpeksag, @serhiy-storchaka

^{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:

assignee = None
closed_at = <Date 2016-04-16.18:25:35.452>
created_at = <Date 2015-08-24.14:15:48.599>
labels = ['type-feature', 'library']
title = "assertWarnsRegex doesn't allow multiple warning messages"
updated_at = <Date 2016-04-16.18:25:35.417>
user = 'https://bugs.python.org/sleepycal'

bugs.python.org fields:

activity = <Date 2016-04-16.18:25:35.417>
actor = 'berker.peksag'
assignee = 'none'
closed = True
closed_date = <Date 2016-04-16.18:25:35.452>
closer = 'berker.peksag'
components = ['Library (Lib)']
creation = <Date 2015-08-24.14:15:48.599>
creator = 'sleepycal'
dependencies = []
files = []
hgrepos = []
issue_num = 24922
keywords = []
message_count = 5.0
messages = ['249048', '258558', '261718', '263571', '263574']
nosy_count = 7.0
nosy_names = ['rbcollins', 'ezio.melotti', 'michael.foord', 'sleepycal', 'berker.peksag', 'serhiy.storchaka', 'superluser']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue24922'
versions = ['Python 3.6']

[sleepycal]

There was a discussion/patch in bpo-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).

[superluser]

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?

[rbtcollins]

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.

[serhiy-storchaka]

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.

[berkerpeksag]

Agreed. Let's close this then.