Description

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'

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

1. sleepycal commented on Aug 24, 2015

   

   sleepycalmannequin

   on Aug 24, 2015

   MannequinAuthor

   More actions

   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).
2. sleepycal

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   on Aug 24, 2015
3. superluser commented on Jan 18, 2016

   

   superlusermannequin

   on Jan 18, 2016

   Mannequin

   More actions

   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?
4. rbtcollins commented on Mar 14, 2016

   

   rbtcollins

   on Mar 14, 2016

   Member

   More actions

   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.
5. berkerpeksag

   added

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   type-featureA feature request or enhancementA feature request or enhancement

   and removed

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Apr 16, 2016
6. serhiy-storchaka commented on Apr 16, 2016

   

   serhiy-storchaka

   on Apr 16, 2016

   Member

   More actions

   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.
7. berkerpeksag commented on Apr 16, 2016

   

   berkerpeksag

   on Apr 16, 2016

   Member

   More actions

   Agreed. Let's close this then.
8. berkerpeksag

   closed this as completedon Apr 16, 2016
9. ezio-melotti

   transferred this issue fromon Apr 10, 2022

Issue actions