Fix logging error message #22276
Fix logging error message #22276
Conversation
|
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! |
Lib/logging/__init__.py
Outdated
| @@ -191,10 +191,11 @@ def _checkLevel(level): | |||
| rv = level | |||
| 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.
Lib/logging/__init__.py
Outdated
| 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.
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
|
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 |
|
Thanks for making the requested changes! @vsajip: please review the changes made to this pull request. |
|
A Travis build appears to have stalled. I'll close and re-open, then test with buildbots. |
|
Build still stalled on Travis job. Closing and reopening to see if that unblocks it. |
|
@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. |
|
Closing for #22276 |
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
Not 100% sure if this needs an issue since I considered it trivial at first --
masterhas this pattern:this fails if
levelis a tuple. This PR switches tof-string, but an alternative to keep%would be just to do% (level,).But when implementing a test by reusing
assert_error_messageI noticed thatassert_error_messagewas 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 toassert_error_message, which then required fixing a few existing tests inFormatterTest, as the messages were actually outdated.