ENH: Pypy fixes #8103
ENH: Pypy fixes #8103
Conversation
|
Note that style fixup commit messages start with |
|
Fixed the non-standard commit message. I tried simply moving the scalarmath.c.src file from umath to multiarray, but there was a link error "PyUFunc_getfperr isn't defined". I guess that falls into the couple of things that need fixing category. It may be simpler to separate the two issues: merge this pull request to allow PyPy to move closer to compatibility, and at some future point in time move the scalar math into multiarray. |
|
I wasn't suggesting that you move the files :0 It was just a reminder to myself (and others) of what should be done. |
|
ping. It would be nice if this made it into 1.12 ... |
|
This all looks pretty trivially correct to me. Except the function pointer stuff, whose motivation is obscure as heck and like Chuck says should just go away once we refactor multiarray/umath properly, but in the mean time the actual changes are totally harmless looking. So let's do this. |
This pull request is the latest in my PyPy compatibility work.
987077b is cleanup from the last pull request.
a5a3bf4 and d34d26f are self-explanatory.
bcda1c5 is needed since when importing scalar_math the tp_as_number function pointers are overridden with more optimal functions, which happens much after PyType_Ready establishes the function wrappers in RPython. In general, changing a type after PyType_Ready is disallowed, but PyType_Ready internally sets up a RPython type with address-to-function-pointer placeholders to the functions. This only works if they are present on the tp_as_... structures, since some types depend on those pointers-to-functions being NULL.