BUG: Work around past and present PEP3118 issues in ctypes #11277
Conversation
3f2c622 to
d86c1ad
Compare
0457b33 to
ae4b7af
Compare
numpy/core/_internal.py
Outdated
| # determine if an object comes from ctypes, in order to work around | ||
| # a bug in the buffer protocol for those objects, bpo-10746 | ||
| try: | ||
| return 'ctypes' in type(obj).__mro__[-2].__module__ |
There was a problem hiding this comment.
__mro__ is only available for new style classes, might be a problem in Python 2.7.
There was a problem hiding this comment.
Although I suspect anything that inherits from ctypes is going to be a new style class, so this should be OK. Maybe a note?
There was a problem hiding this comment.
Yep, it seemed that ctypes classes are always new-style
numpy/core/_internal.py
Outdated
| try: | ||
| return 'ctypes' in type(obj).__mro__[-2].__module__ | ||
| except Exception: | ||
| return False |
numpy/core/src/multiarray/ctors.c
Outdated
| } | ||
| } | ||
| else { | ||
| descr = PyArray_DescrNewFromType(NPY_STRING); |
There was a problem hiding this comment.
Maybe note on string assumption.
| @@ -1315,27 +1356,73 @@ _array_from_buffer_3118(PyObject *memoryview) | |||
| npy_intp shape[NPY_MAXDIMS], strides[NPY_MAXDIMS]; | |||
|
|
|||
| view = PyMemoryView_GET_BUFFER(memoryview); | |||
There was a problem hiding this comment.
Is it safe to assume that memoryview is actually a memoryview?
There was a problem hiding this comment.
Yes, because this function is only ever called with one, I think
| if (descr == NULL) { | ||
| return NULL; | ||
| } | ||
| if (descr->elsize != view->len) { |
There was a problem hiding this comment.
I'm confused here as view->len should be the total size of the memory. What am I missing?
There was a problem hiding this comment.
We're creating an 0d array below with one (compound) element - so the dtype should span the total size of the memory
There was a problem hiding this comment.
A comment somewhere would help, as that is a bit unexpected. At least, I didn't expect it :)
|
Couple of nits and a question. |
ae4b7af to
e85efc7
Compare
…ype(ctype_obj)) Fixes numpygh-10528 Fixes numpygh-10978 Fixes numpygh-11150 A warning is thrown when ctypes misbehaves, in order to not hide issues that need fixing upstream
e85efc7 to
1e5df66
Compare
|
Comments improved |
Fixes gh-10528
Fixes gh-10978
Fixes gh-11150
It seems we already have some
ctype -> dtypecode that we can fall back on in the frequent cases where ctypes give the wrong pep3118 buffer.This is kind of unfortunate - I was hoping to implement
ctype -> dtypein terms of the PEP3118 buffer code (#10533 (comment)), but it seems that we have to fall back on the reverse here