[Numpy-discussion] Status of NumPy and Python 3.3

Ondřej Čertík ondrej.certik@gmail....
Sun Jul 29 10:12:43 CDT 2012


On Sun, Jul 29, 2012 at 6:56 AM, Stefan Krah <stefan-usenet@bytereef.org> wrote:
> Ond??ej ??ert??k <ondrej.certik@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


More information about the NumPy-Discussion mailing list