On Sun, Jul 29, 2012 at 6:56 AM, Stefan Krah <stefan-use...@bytereef.org> wrote: > Ond??ej ??ert??k <ondrej.cer...@gmail.com> wrote: >> https://github.com/numpy/numpy/pull/366 > > Using Python 3.3 compiled --with-pydebug it appears to be impossible > to fool the new Unicode implementation with byte-swapped data: > > > Apply the patch from: > > http://projects.scipy.org/numpy/ticket/2193 > > > Then: > > Python 3.3.0b1 (default:68e2690a471d+, Jul 29 2012, 15:28:41) > [GCC 4.4.3] on linux > Type "help", "copyright", "credits" or "license" for more information. >>>> from numpy import array > [206376 refs] >>>> a = array(["abc"]) > [206382 refs] >>>> b = a.newbyteorder() > [206387 refs] >>>> b > python3.3: Objects/unicodeobject.c:401: _PyUnicode_CheckConsistency: > Assertion `maxchar <= 0x10ffff' failed. > > Program received signal SIGABRT, Aborted. > 0x00007ffff71e6a75 in *__GI_raise (sig=<value optimized out>) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > in ../nptl/sysdeps/unix/sysv/linux/raise.c > (gdb) > > > This should be expected since the byte-swapped strings aren't valid.
Exactly, I am aware that my solution is a hack. So is the Python 3.2 solution, except that Python 3.2 doesn't seem to have the _PyUnicode_CheckConsistency() function, so no checks are done. As such, I think that my PR simply extends the numpy approach to Python 3.3. A separate issue is that the swapping thing is a hack -- Travis, what is the purpose of the newbyteorder() and the need to swap the internals of the unicode object? Ondrej _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
