-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
gh-126476: Raise IllegalMonthError
for calendar.formatmonth method when the input month is not corret
#126484
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
Conversation
…ethod when the input month is not corret
I'm not sure this is a good idea. If someone was catching |
Yeah, Eric is right. I would be ok with this if |
I have update this PR,PTAL @ericvsmith @ZeroIntensity |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to feel about this. It works, and the implementation looks fine, but it's also a little hacky so I'm hesitant to approve. I'll wait for Eric's input.
Yeah, I'm not crazy about it. It seems like there must be other places where we've done something similar, though. Does anyone feel like searching the stdlib for some place else we've done this? |
I didn't find any examples of errors inheriting from |
I was thinking more along the lines of using multiple inheritance for exceptions. But those are good examples of changing the type of an exception. |
Ah sorry, I misunderstood. I checked again and found two examples of multiple inheritance: class MultipartConversionError(MessageError, TypeError):
"""Conversion to a multipart is prohibited."""
class UnsupportedOperation(OSError, ValueError):
pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multiple inheritance for exceptions is a common technique (at least in my own code 😄 ). Looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Tomas for finding examples! I'd vote that it's probably okay to change the exception type. Adding IndexError
as a base can break code too if someone has an except IndexError
for some other reason and calls monthrange
.
(side note: the UnsupportedOperation
Tomas mentions has finicky history)
Misc/NEWS.d/next/Library/2024-11-06-18-30-50.gh-issue-126476.F1wh3c.rst
Outdated
Show resolved
Hide resolved
Thanks @Zheaoli for the PR, and @ethanfurman for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12. |
Thanks @Zheaoli for the PR, and @ethanfurman for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13. |
…hen the input month is not correct (pythonGH-126484) (cherry picked from commit 3be7498) Co-authored-by: Nadeshiko Manju <me@manjusaka.me> Co-authored-by: Ethan Furman <ethan@stoneleaf.us>
GH-126878 is a backport of this pull request to the 3.12 branch. |
…hen the input month is not correct (pythonGH-126484) (cherry picked from commit 3be7498) Co-authored-by: Nadeshiko Manju <me@manjusaka.me> Co-authored-by: Ethan Furman <ethan@stoneleaf.us>
GH-126879 is a backport of this pull request to the 3.13 branch. |
…when the input month is not correct (GH-126484) (GH-126878) gh-126476: Raise IllegalMonthError for calendar.formatmonth() when the input month is not correct (GH-126484) (cherry picked from commit 3be7498) Co-authored-by: Nadeshiko Manju <me@manjusaka.me> Co-authored-by: Ethan Furman <ethan@stoneleaf.us>
…when the input month is not correct (GH-126484) (GH-126879) gh-126476: Raise IllegalMonthError for calendar.formatmonth() when the input month is not correct (GH-126484) (cherry picked from commit 3be7498) Co-authored-by: Nadeshiko Manju <me@manjusaka.me> Co-authored-by: Ethan Furman <ethan@stoneleaf.us>
…hen the input month is not correct (pythonGH-126484) Co-authored-by: Ethan Furman <ethan@stoneleaf.us>
…hen the input month is not correct (pythonGH-126484) Co-authored-by: Ethan Furman <ethan@stoneleaf.us>
Fix: #126476