[Numpy-discussion] Status of NumPy and Python 3.3
Stefan Krah
stefan-usenet@bytereef....
Sun Jul 29 05:40:34 CDT 2012
Ond??ej ??ert??k <ondrej.certik@gmail.com> wrote:
> Well, I simply went to the Python sources and then implemented a
> solution that works with this patch:
>
> https://github.com/certik/numpy/commit/36fcd1327746a3d0ad346ce58ffbe00506e27654
> https://github.com/numpy/numpy/pull/366
Nice! I hit the same problem yesterday: unicode_new() does not accept
byte-swapped input with an encoding, since the input is not valid. But
your solution circumvents the validation.
I'm not sure what the use case is for byte-swapped (invalid?) unicode
strings, but the approach looks good to me in the sense that it does
the same thing as the Py_UNICODE_WIDE path in 3.2.
In PyArray_Scalar() I only have these comments, two of which are stylistic:
- I think the 'size' parameter in PyUnicode_New() refers to the number
of code points (UCS4 in this case), so:
PyUnicode_New(itemsize >> 2, max_char)
- The 'b' variable could be renamed to 'u' now.
- PyArray_Scalar() is beginning to look a little crowded. Perhaps the whole
PY_VERSION_HEX >= 0x03030000 block could go into a separate function such
as:
NPY_NO_EXPORT PyObject *
get_unicode_scalar_3_3(PyTypeObject *type, void *data, Py_ssize_t itemsize,
int swap);
Then there's another problem in numpy.test() if Python 3.3 is compiled
--with-pydebug:
.python3.3: numpy/core/src/multiarray/common.c:161: PyArray_DTypeFromObjectHelper: Assertion `((((((PyObject*)(temp))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.
Aborted
Stefan Krah
More information about the NumPy-Discussion
mailing list