-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
bpo-35021: Fixes assertion failures in _datetimemodule.c #10039
bpo-35021: Fixes assertion failures in _datetimemodule.c #10039
Conversation
Fixes assertion failures in _datetimemodule.c introduced in the previous fix. Rather of trying to handle an int subclass as exact int, let it to use overridden special methods, but check the result of divmod().
@@ -2309,13 +2315,11 @@ accum(const char* tag, PyObject *sofar, PyObject *num, PyObject *factor, | |||
assert(num != NULL); | |||
|
|||
if (PyLong_Check(num)) { | |||
prod = PyNumber_Multiply(factor, num); | |||
prod = PyNumber_Multiply(num, factor); |
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.
same comment as the other PR: add a comment on the PyNumber_Multiply calls describing why the order might matter.
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.
The order doesn't matter now. I just restore the order prior to bpo-31752 changes.
This looks good to me, and seems like the most sensible approach. |
Although #10040 is closer to the Python implementation. |
Thanks @serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 2.7, 3.6, 3.7. |
Fixes assertion failures in _datetimemodule.c introduced in the previous fix (see bpo-31752). Rather of trying to handle an int subclass as exact int, let it to use overridden special methods, but check the result of divmod(). (cherry picked from commit 3ec0f49) Co-authored-by: Serhiy Storchaka <[email protected]>
GH-10614 is a backport of this pull request to the 3.7 branch. |
Fixes assertion failures in _datetimemodule.c introduced in the previous fix (see bpo-31752). Rather of trying to handle an int subclass as exact int, let it to use overridden special methods, but check the result of divmod(). (cherry picked from commit 3ec0f49) Co-authored-by: Serhiy Storchaka <[email protected]>
GH-10615 is a backport of this pull request to the 3.6 branch. |
Sorry, @serhiy-storchaka, I could not cleanly backport this to |
Fixes assertion failures in _datetimemodule.c introduced in the previous fix (see bpo-31752). Rather of trying to handle an int subclass as exact int, let it to use overridden special methods, but check the result of divmod(). (cherry picked from commit 3ec0f49) Co-authored-by: Serhiy Storchaka <[email protected]>
Fixes assertion failures in _datetimemodule.c introduced in the previous fix (see bpo-31752). Rather of trying to handle an int subclass as exact int, let it to use overridden special methods, but check the result of divmod(). (cherry picked from commit 3ec0f49) Co-authored-by: Serhiy Storchaka <[email protected]>
…GH-10039) Fixes assertion failures in _datetimemodule.c introduced in the previous fix (see bpo-31752). Rather of trying to handle an int subclass as exact int, let it to use overridden special methods, but check the result of divmod().. (cherry picked from commit 3ec0f49) Co-authored-by: Serhiy Storchaka <[email protected]>
GH-10617 is a backport of this pull request to the 2.7 branch. |
…) (GH-10617) Fixes assertion failures in _datetimemodule.c introduced in the previous fix (see bpo-31752). Rather of trying to handle an int subclass as exact int, let it to use overridden special methods, but check the result of divmod(). (cherry picked from commit 3ec0f49) Co-authored-by: Serhiy Storchaka <[email protected]>
|
Fixes assertion failures in _datetimemodule.c
introduced in the previous fix (bpo-31752).
Rather of trying to handle an int subclass as exact int,
let it to use overridden special methods, but check the
result of divmod().
https://bugs.python.org/issue35021