-
-
Notifications
You must be signed in to change notification settings - Fork 31k
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
gh-64376: Use Argument Clinic for datetime.date classmethods #20208
Conversation
Note that this will now throw OverflowError instead of ValueError when using the C version of datetime. There is precedent for this, e.g., datetime.date.fromordinal will throw an OverflowError with the C module but ValueError with the Python.
Re: |
Two small notes:
|
Indeed, it's good to keep these Argument Clinic conversions as straightforward as possible. |
Closing and re-opening to restart the hanged Travis-CI check. |
Thanks, looks like everything's green :-) |
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 for this!
Needs a few tweaks but overall looks good.
(2<<32, 1, 1), | ||
(2019, 2<<32, 1), | ||
(2019, 1, 2<<32), |
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.
Why are these removed?
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 mentioned this in a PR comment:
Re: datetime.date.fromisocalendar
Note that this now can throw OverflowError instead of ValueError when
using the C version of datetime. There is precedent for this, e.g.,
datetime.date.fromordinal
will throw an OverflowError with the C module
but ValueError with the Python.
Also, prior to this PR, the C version fromisocalendar
would throw a ValueError while the Python version throws TypeError for issues with e.g, missing arguments.
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.
Ah, thanks, I didn't make the connection! I'll take another look at that.
Misc/NEWS.d/next/Library/2020-05-19-06-32-11.bpo-20177.BwGrIX.rst
Outdated
Show resolved
Hide resolved
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 |
Co-authored-by: Tal Einat <[email protected]>
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 for the review! :-)
In my opinion this is fine, huge PRs can be hard to work with. |
if (PyErr_ExceptionMatches(PyExc_OverflowError)) { | ||
PyErr_Format(PyExc_ValueError, | ||
"ISO calendar component out of range"); | ||
year: int | ||
week: int | ||
day: int | ||
|
||
} |
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.
Now I see that before this PR we have code in fromisocalendar()
to raise ValueError rather than OverflowError. Raising a ValueError seems like better behavior to me. Also, changing this would be considered backwards-incompatible, would require NEWS and What's New entries, and couldn't be backported.
I think we should find a way to retain this behavior, even if that means not using Argument Clinic for this method right now.
To respond to all points re. types of exceptions raised:
As I stated above, I suggest keeping the behavior of raising ValueError rather than OverflowError.
Changing this to raise ValueError instead of OverflowError would be an improvement IMO.
These inconsistencies are unfortunate, but relatively minor. If this PR fixes that, adding a test for it would be great! |
@hauntsaninja could you fix merge conflicts, please? |
https://bugs.python.org/issue20177