-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
BUG: Stack overflow on double inheritance from numpy.flexible and numpy.ma.core.MaskedArray #23737
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
Comments
Thanks! |
The memoryview() part in my original report was unnecessary; just instantiating the class is enough:
|
* Fixes numpy#23737 * based on the discussion in the issue above, this completely blocks subclassing `np.flexible` at the Python level and adds a test to ensure the segfault codepath is no longer accessible
* Fixes numpy#23737 * based on the discussion in the issue above, this completely blocks subclassing `np.flexible` at the Python level and adds a test to ensure the segfault codepath is no longer accessible
@seberg could you expand on " Reopening for discussion. |
I think CPython is fine with allowing it in C presuming you know what you do, but not sure it is intentional or not. Yes, I suppose you are right. Subclassing it makes in theory sense (honestly, I don't think it does in practice, you cannot have a flexible user dtype in the old machinery anyway). So yes, it makes a bit more sense to allow it, but move the actual buffer stuff to the concrete subclasses, becasuse there is no reason to have anything related in the superclass. I am not even sure if it is used there, so maybe it can just be deleted from there. |
* Fixes numpy#23737 * based on the discussion in the issue above, this completely blocks subclassing `np.flexible` at the Python level and adds a test to ensure the segfault codepath is no longer accessible Signed-off-by: Filipe Laíns <[email protected]>
Describe the issue:
Reproduce the code example:
Error message:
Runtime information:
Context for the issue:
No concrete use case; I found this while trying to instantiate all pairs of buffer classes to look for real-world impact of python/cpython#104297.
The text was updated successfully, but these errors were encountered: