[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