[Numpy-discussion] Status of NumPy and Python 3.3
Sat Jul 28 04:36:22 CDT 2012
Ond??ej ??ert??k <firstname.lastname@example.org> 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.
> 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)
More information about the NumPy-Discussion