[Numpy-discussion] Status of NumPy and Python 3.3

Stefan Krah stefan-usenet at bytereef.org
Sat Jul 28 05:36:22 EDT 2012


Ond??ej ??ert??k <ondrej.certik at gmail.com> wrote:
> >> I took a brief look at it, and from the errors I have seen, one is
> >> cosmetic, the other one is a bit more involved (rewriting
> >> PyArray_Scalar unicode support). While it is not difficult in nature,
> >> the current code has multiple #ifdef of Py_UNICODE_WIDE, meaning it
> >> would require multiple configurations on multiple python versions to
> >> be tested.

The cleanest way might be to leave the existing code in place and write
completely new and independent code for Python 3.3.


> https://github.com/numpy/numpy/pull/366
> 
> It's a work in progress, I am still have some little issues, see the
> PR for up-to-date details.

I'm not a Unicode expert, but I think it's best to avoid Py_UNICODE altogether.

What should matter in 3.3 is the maximum character in a Unicode string that
determines the kind of the string:

   PyUnicode_1BYTE_KIND  ->  Py_UCS1
   PyUnicode_2BYTE_KIND  ->  Py_UCS2
   PyUnicode_4BYTE_KIND  ->  Py_UCS4


So Py_UNICODE_WIDE should not matter as all builds support PyUnicode_4BYTE_KIND.
That's why I /think/ it's possible to drop Py_UNICODE altogether. For instance,
the line in https://github.com/certik/numpy/commit/d02e36e5c85d5ee444614254643037aafc8deccc
should probably be:

  itemsize = PyUnicode_GetLength(robj) * PyUnicode_KIND(robj)



Stefan Krah





More information about the NumPy-Discussion mailing list