-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
BUG: have _array_from_buffer_3118
correctly handle errors
#10882
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
5ca9322
to
8c479ee
Compare
numpy/core/tests/test_multiarray.py
Outdated
# construct a memoryview with 33 dimensions | ||
ct = ctypes.c_uint8 | ||
for i in range(33): | ||
ct = 1 * ct |
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.
Tests fail due to a reference cycle involving ct
, which is somehow detected in a completely different test. Printing gc.garbage
in the failing test gives:
# ndim = 18
A = numpy.core.tests.test_multiarray.c_ubyte_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1
B = numpy.core.tests.test_multiarray.c_ubyte_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1
[<class 'A'>,
(<class 'A'>,
<class '_ctypes.Array'>,
<class '_ctypes._CData'>,
<class 'object'>),
{'__dict__': <attribute '__dict__' of 'A' objects>,
'__doc__': None,
'__module__': 'numpy.core.tests.test_multiarray',
'__weakref__': <attribute '__weakref__' of 'A' objects>,
'_length_': 1,
'_type_': <class 'B'>},
<attribute '__weakref__' of 'A' objects>,
<attribute '__dict__' of 'A' objects>]
This happens even if we remove the np.array
call below, so the problem must be in either CPython, or parallelization in pytest
Fixes numpygh-6741 If an object claims to support the PEP3118 buffer protocol, then any mistakes in the implementation should be raised as errors, rather than falling back on other approaches. This has some behavior changes: * np.array(mem_view_33d) now gives a more useful error message than "memoryview: unsupported format <B" * np.array(ctypes_pointer) now errors rather than creating an object array containing a single pointer Also adds support for 32-dimensional buffers, where previously the max was 31-dimensional.
99bf2ca
to
e6ee8d3
Compare
e6ee8d3
to
63e9cfb
Compare
Thanks Eric. |
I'm not 100% confident that the behavior this patch fixes wasn't something that we rely upon. In particular, perhaps |
Yeah, I figure we will find out, and if not, it probably doesn't matter. But if you come upon some info that suggests it does matter, please update. These changes in behavior are tricky, but sometimes worth exploring. |
Yep, this broke |
Everything behaves a lot better if we let the array constructor handle it, which will use the ctypes PEP3118 support. Bugs this fixes: * Stale state being attached to pointer objects (fixes numpygh-2671, closes numpygh-6214) * Weird failure modes on structured arrays (fixes-10978) * A regression in numpygh-10882 (fixes numpygh-10968)
_array_from_buffer_3118
correctly handle errors
Everything behaves a lot better if we let the array constructor handle it, which will use the ctypes PEP3118 support. Bugs this fixes: * Stale state being attached to pointer objects (fixes numpygh-2671, closes numpygh-6214) * Weird failure modes on structured arrays (fixes-10978) * A regression in numpygh-10882 (fixes numpygh-10968)
Fixes gh-6741, closes gh-9348
If an object claims to support the PEP3118 buffer protocol, then any mistakes in the implementation should be raised as errors, rather than falling back on other approaches.
This has some behavior changes:
Also adds support for 32-dimensional buffers, where previously the max was 31-dimensional.