-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
BUG: Do not crash on recursive .dtype
attribute lookup.
#13003
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
fdbab42
to
2aa6521
Compare
new->names = conv->names; | ||
Py_INCREF(new->names); | ||
Py_XINCREF(new->names); |
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.
Is this a bug fix?
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.
Yes, although it might be that the bug it fixes is in paths that normal code should not reach.
Generally looks good. Perhaps you should split the deprecation into a separate PR - I think this is close to being ready, but with the deprecation in place it would maybe need to hit the mailing list. Would be a shame to block the bug fix on that. |
2aa6521
to
a80e323
Compare
Split off the deprecation (and that funny maintanence of the tests) into gh-13578. |
a80e323
to
929910b
Compare
The code path in scalarapi.c which checks dtype on one inheriting from np.void is especially awkward and was completely untested previously. So I am not sure we should even support it at all. Closes numpygh-12982, numpygh-3614, and numpygh-12751
929910b
to
65da904
Compare
@eric-wieser any more review comments? |
As an error is better than a segfault, thanks @seberg |
The code path in scalarapi.c which checks dtype on one inheriting
from np.void is especially awkward and was completely untested
previously. So I am not sure we should even support it at all.
Closes gh-12982, gh-3614, and gh-12751
Frankly, I am not sure it is actually worth the trouble, but had started on it. The actual error message does not always include the custom message, this seems because the recursion error can also be triggered by the
GetAttr
call (at least when dtype is made a property).If we attack dtypes in any case, I am afraid adding more band-aids will just make things harder in the long run anyway.