-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
gh-112636: remove check for float subclasses without nb_float #112637
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
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
CC @vstinner, does it make sense for you? |
I don't understand the example. float(a) does now return XXX? Or does it print XXX? Which part of the code prints XXX? |
Ah, that was just a debug print from the removed (by this pr) code. I've added a diff to description. The point is that to trigger that code - you must explicitly set nb_float field in the derived class to NULL. But in this way we can break everything! Can't you set nb_add to NULL in a float subclass? Easy! But CPython has enough code, which assuming that float subclasses have working arithmetic dunder methods. |
What is the behavior on this |
It fails with TypeError (after you run first
Yes, because |
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.
This change is a backward incompatible change. You should document it in a NEWS entry.
Sorry, but I now think that we should rather return a fallback for integers. |
Ok, I did. News entry was missed just as in 31a6554 (dropped similar check in PyNumber_Long).
But why?! Should we check on same ground that an int subtype has nb_add field set? |
Because |
In same way we can recover in case when float subtype sets e.g. nb_negative to |
Misc/NEWS.d/next/C_API/2024-10-01-14-53-55.gh-issue-112636.t4WJjC.rst
Outdated
Show resolved
Hide resolved
Misc/NEWS.d/next/C_API/2024-10-01-14-53-55.gh-issue-112636.t4WJjC.rst
Outdated
Show resolved
Hide resolved
Co-authored-by: Victor Stinner <vstinner@python.org>
There is a difference, if nb_int is set to Lines 1403 to 1405 in 31516c9
and Lines 1446 to 1448 in 31516c9
I still think we shouldn't keep workarounds for broken subtypes. But if so, at least the nb_int workaround shouldn't be restored. |
Ok, I'm closing this. |
This condition could be triggered only in very special scenario, if users code explicitly override inherited
nb_float
value and set it toNULL
: