Ond??ej ??ert??k <ondrej.cer...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
