[Numpy-discussion] Status of NumPy and Python 3.3

Ondřej Čertík ondrej.certik@gmail....
Sun Jul 29 10:50:03 CDT 2012

On Sun, Jul 29, 2012 at 3:40 AM, Stefan Krah <stefan-usenet@bytereef.org> wrote:
> 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)

Right. Done.

>    - 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);

I didn't do this, as I think the function is fine as it is. If further
refactoring is needed, then one should
probably create 3 functions, one for 3.3, one for <3.3-wide and one
for <3.3-narrow.

I've also rebased and squashed the commits, so now it is ready to be merged:


Thanks Stefan for your help.

Can somebody with push access please review it?


More information about the NumPy-Discussion mailing list