| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA). Recognized GitHub usernameWe couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames: This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for the contribution, we look forward to reviewing it! |
Sorry, something went wrong.
| elif str(level) == level: | ||
| if level not in _nameToLevel: | ||
| raise ValueError("Unknown level: %r" % level) | ||
| raise ValueError(f"Unknown level: {repr(level)}") |
There was a problem hiding this comment.
To get to this code you would need to have passed the test str(level) == level, how would a tuple do this? I wouldn't think this line needs changing.
Sorry, something went wrong.
| rv = _nameToLevel[level] | ||
| else: | ||
| raise TypeError("Level not an integer or a valid string: %r" % level) | ||
| raise TypeError("Level not an integer or a valid string: " |
There was a problem hiding this comment.
This could just be "Level not an integer or a valid string: %s" % repr(level) which should always work. I'm not against f-strings, but there is no need to introduce them here for this purpose.
Sorry, something went wrong.
There was a problem hiding this comment.
I went with "...: %r" % (level,)" since it's closer to the old code, but happy to push a commit to go with your variant if you want
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
I have made the requested changes; please review again |
Sorry, something went wrong.
|
Thanks for making the requested changes! @vsajip: please review the changes made to this pull request. |
Sorry, something went wrong.
|
A Travis build appears to have stalled. I'll close and re-open, then test with buildbots. |
Sorry, something went wrong.
|
Build still stalled on Travis job. Closing and reopening to see if that unblocks it. |
Sorry, something went wrong.
|
@larsoner This PR is unfortunately blocked from merge due to a problem with either GitHub or Travis (not sure which, as it seems to be in the interface between them). If you're in a hurry to progress this, it might be an idea to create a new PR with your current changes, and seeing if that one can go through (don't close this PR, though, it might be useful for diagnosing the GH/Travis problem). Discussion here. |
Sorry, something went wrong.
Same changes as python#22276 squashed to a single commit. Just hoping to get Travis to cooperate by opening a new PR... Automerge-Triggered-By: @vsajip
| Back | FazBrowse Home | New Git URL |
Not 100% sure if this needs an issue since I considered it trivial at first -- master has this pattern:
raise ValueError("Unknown level: %r" % level)this fails if level is a tuple. This PR switches to f-string, but an alternative to keep % would be just to do % (level,).
But when implementing a test by reusing assert_error_message I noticed that assert_error_message was not doing what I think it was intended to do -- it never really checked to make sure the emitted error message actually matched the given error message. So I refactored it to actually check that the error message matched the one passed to assert_error_message, which then required fixing a few existing tests in FormatterTest, as the messages were actually outdated.