Thanks to visit codestin.com
Credit goes to github.com

Skip to content

bpo-40679: use a function's qualname in error messages #20236

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
May 22, 2020

Conversation

sweeneyde
Copy link
Member

@sweeneyde sweeneyde commented May 19, 2020

Copy link
Member

@cjerdonek cjerdonek left a comment

Choose a reason for hiding this comment

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

Here are a couple comments. Thanks for the PR!

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@@ -4180,7 +4181,7 @@ _PyEval_EvalCode(PyThreadState *tstate,
if (keyword == NULL || !PyUnicode_Check(keyword)) {
_PyErr_Format(tstate, PyExc_TypeError,
"%U() keywords must be strings",
co->co_name);
qualname);
Copy link
Member Author

Choose a reason for hiding this comment

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

Are there any suggestions for how to test this from Python? I couldn't figure out how without getting a SyntaxError.

Copy link
Contributor

@SylvainDe SylvainDe May 20, 2020

Choose a reason for hiding this comment

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

Using the ** should do the trick.
For example:

>>> func = lambda *args, **kwargs: None
>>> kwargs = {None: None}
>>> func(kwargs)
>>> func(*kwargs)
>>> func(**kwargs)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: <lambda>() keywords must be strings

Copy link
Member Author

Choose a reason for hiding this comment

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

Unfortunately it looks like this behavior changed a bit in the newest releases so that that code isn't actually reached:

PS > py -3.7 -c "f = lambda x: None; f(**{1:1})"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: <lambda>() keywords must be strings
PS > py -3.8 -c "f = lambda x: None; f(**{1:1})"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: <lambda>() keywords must be strings
PS > py -3.9 -c "f = lambda x: None; f(**{1:1})"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: keywords must be strings

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh I see... Probably related to 0567786 .

Copy link
Member

@cjerdonek cjerdonek left a comment

Choose a reason for hiding this comment

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

I think the earlier version where you're using traditional TestCase classes is a bit better because it's more idiomatic. I'm not sure why that large doctest is being used like that.

Also, since assertRaisesRegex() is annoying to use when you're just trying to test equality, you could define a context manager helper method on your test class as your own replacement. It could look something like this:

with self.assertRaises(TypeError) as cm:
    yield
exc = cm.exception
self.assertEqual(str(exc), '<message>')

That would eliminate some boilerplate.

@sweeneyde
Copy link
Member Author

@cjerdonek I switched it back to a standard unittest.TestCase and refactored as you suggested.

Copy link
Member

@cjerdonek cjerdonek left a comment

Choose a reason for hiding this comment

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

Good work! A few nits, and I think this is good to go. 👍

@sweeneyde
Copy link
Member Author

One of the tests (test_ttk_guionly) on Ubuntu is hanging on this line:

but I think that is unrelated. I think this might be a common intermittent issue.

@sweeneyde sweeneyde closed this May 21, 2020
@sweeneyde sweeneyde reopened this May 21, 2020
@cjerdonek
Copy link
Member

cjerdonek commented May 21, 2020 via email

@cjerdonek
Copy link
Member

cjerdonek commented May 21, 2020 via email

@sweeneyde
Copy link
Member Author

Thanks -- good to know.

I opened https://bugs.python.org/issue40722.

@cjerdonek cjerdonek merged commit b5cc208 into python:master May 22, 2020
@cjerdonek
Copy link
Member

Thanks again for your good work on this, @sweeneyde.

arturoescaip pushed a commit to arturoescaip/cpython that referenced this pull request May 24, 2020
archlinux-github pushed a commit to archlinux/svntogit-community that referenced this pull request Dec 4, 2021
Related tickets/PRs:
* python/cpython#20236
* https://twistedmatrix.com/trac/ticket/10273

git-svn-id: file:///srv/repos/svn-community/svn@1065036 9fca08f4-af9d-4005-b8df-a31f2cc04f65
archlinux-github pushed a commit to archlinux/svntogit-community that referenced this pull request Dec 4, 2021
Related tickets/PRs:
* python/cpython#20236
* https://twistedmatrix.com/trac/ticket/10273



git-svn-id: file:///srv/repos/svn-community/svn@1065036 9fca08f4-af9d-4005-b8df-a31f2cc04f65
@sweeneyde sweeneyde deleted the func_qualname branch January 25, 2022 23:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants