Repository navigation
assertWarnsRegex doesn't allow multiple warning messages #69110
Description
| 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']
Activity
sleepycal commented on Aug 24, 2015
There was a discussion/patch in bpo-9754 1.
This allows for multiple warning types as a tuple, e.g.;
However, it does not allow testing for multiple warning messages, e.g.;
This is slightly unexpected, as test.support.check_warnings allows this behaviour, e.g.
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 commented on Jan 18, 2016
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:
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:
Would lineno and filename become lists? It seems kind of ugly. What's the advantage over simply testing for each warning separately?
rbtcollins commented on Mar 14, 2016
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 commented on Apr 16, 2016
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 commented on Apr 16, 2016
Agreed. Let's close this then.