On Sun, Jul 29, 2012 at 3:40 AM, Stefan Krah <stefan-use...@bytereef.org> wrote: > Ond??ej ??ert??k <ondrej.cer...@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. Done. > > - 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: https://github.com/numpy/numpy/pull/366 Thanks Stefan for your help. Can somebody with push access please review it? Ondrej _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
