Skip to content

Conversation

@orenmn
Copy link
Contributor

@orenmn orenmn commented Aug 27, 2017

  • in _warnings.c: add checks whether the return value of the received loader's get_source() is invalid.
  • in test_warnings/__init__.py: add tests to verify the assertion failure and the SystemError are no more.

https://bugs.python.org/issue31285


/* Split the source into lines. */
source_list = PyObject_CallMethodObjArgs(source,
source_list = PyObject_CallMethodObjArgs((PyObject *)&PyUnicode_Type,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use just PyUnicode_Splitlines().

return splitlines_ret_val
return BadSource()
return BadLoader()
self.assertRaises(IndexError, self.module.warn_explicit,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this test already takes multiple lines, I think it would look clearer if use a context manager form:

with self.assertRaises(IndexError):
     self.module.warn_explicit(...)

But why IndexError is expected? Wouldn't be better to test the normal case that doesn't raise an error? You can use test.support.captured_stderr() for capturing the warning output.

self.assertNotIn(b'Warning!', stderr)
self.assertNotIn(b'Error', stderr)

def test_warn_explicit(self):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This name is too general, but the test isn't a general test of warn_explicit(). Use something more specific like test_issue31285.

'foo', UserWarning, 'bar', 1,
module_globals={'__loader__': _get_bad_loader(42),
'__name__': 'foobar'})
self.assertIn('bar:1: UserWarning: foo', stderr.getvalue())
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure whether this and the other call to assertIn() are necessary, as we want to make sure a SystemError and an assertion failure don't happen...

# warn_explicit() should neither raise a SystemError nor cause an
# assertion failure, in case the return value of get_source() has a
# bad splitlines() method.
def _get_bad_loader(splitlines_ret_val):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Starting underscore is not needed.

del self.module._showwarnmsg
with support.captured_stderr() as stderr:
self.module.warn_explicit(
'foo', ArithmeticError, 'bar', 1,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it valid to use ArithmeticError which is not a warning category?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is valid (IIUC, only warning.warns() requires the category to be a subclass of Warning). I used ArithmeticError because it caused get_filter() to return 'default'. But now it seems quite obscure to me, so I would change it.

Also, my test fails with -Werror, so I would fix that too.

@serhiy-storchaka serhiy-storchaka added needs backport to 2.7 type-bug An unexpected behavior, bug, or error labels Sep 24, 2017
@miss-islington
Copy link
Contributor

Thanks @orenmn for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 2.7, 3.6.
🐍🍒⛏🤖

@miss-islington
Copy link
Contributor

Sorry, @orenmn and @serhiy-storchaka, I could not cleanly backport this to 2.7 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 91fb0afe181986b48abfc6092dcca912b39de51d 2.7

@miss-islington
Copy link
Contributor

Thanks @orenmn for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 2.7, 3.6.
🐍🍒⛏🤖

@miss-islington
Copy link
Contributor

Sorry @orenmn and @serhiy-storchaka, I had trouble checking out the 3.6 backport branch.
Please backport using cherry_picker on command line.
cherry_picker 91fb0afe181986b48abfc6092dcca912b39de51d 3.6

@miss-islington
Copy link
Contributor

Sorry, @orenmn and @serhiy-storchaka, I could not cleanly backport this to 2.7 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 91fb0afe181986b48abfc6092dcca912b39de51d 2.7

serhiy-storchaka pushed a commit to serhiy-storchaka/cpython that referenced this pull request Sep 26, 2017
@bedevere-bot
Copy link

GH-3775 is a backport of this pull request to the 3.6 branch.

@bedevere-bot
Copy link

GH-3805 is a backport of this pull request to the 2.7 branch.

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Sep 29, 2017
serhiy-storchaka pushed a commit that referenced this pull request Sep 29, 2017
serhiy-storchaka pushed a commit that referenced this pull request Sep 29, 2017
orenmn added a commit to orenmn/cpython that referenced this pull request Sep 30, 2017
…) in case __loader__.get_source() has a bad splitlines() method. (pythonGH-3219)
serhiy-storchaka pushed a commit that referenced this pull request Sep 30, 2017
…) in case __loader__.get_source() has a bad splitlines() method. (GH-3219) (#3823)

(cherry picked from commit 91fb0af)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type-bug An unexpected behavior, bug, or error

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants