[Numpy-discussion] PyArray_Scalar should not use memcpy

[Matti Picus]

Hi. This is a heads up and RFC about a pull request I am preparing for
PyArray_Scalar, within the framework of getting NumPy working properly
on PyPy. For those who don't know, the numpy HEAD builds and runs on
PyPy2.7 HEAD (otherwise known as nightly default). However there are a
number of test failures, some are caused by (ab)use of memcpy on c-level
pointers obtained from Py*_FromString().

I am currently rewriting PyArray_Scalar to not use memcpy, and wondering
how deep of a refactoring would be acceptable by the maintainers in a
single pull request? Should I just stick to small changes to eliminate
the two calls to memcpy, or clean up and restructure the entire function
around a more switch(type_num) programming style?

Thanks,
Matti

[Nathaniel Smith]

Post by Matti Picus
Hi. This is a heads up and RFC about a pull request I am preparing for

PyArray_Scalar, within the framework of getting NumPy working properly on
PyPy. For those who don't know, the numpy HEAD builds and runs on PyPy2.7
HEAD (otherwise known as nightly default). However there are a number of
test failures, some are caused by (ab)use of memcpy on c-level pointers
obtained from Py*_FromString().

Post by Matti Picus
I am currently rewriting PyArray_Scalar to not use memcpy, and wondering

how deep of a refactoring would be acceptable by the maintainers in a
single pull request? Should I just stick to small changes to eliminate the
two calls to memcpy, or clean up and restructure the entire function around
a more switch(type_num) programming style?

I don't think anyone is particularly attached to the current internal
structure of the numpy scalars. Beyond that it's hard to say in the
abstract... a small change will certainly be easier and quicker to merge
than a big change, but if you have a good clean up then it'd certainly be
welcome :-). You know better than us how easy it would be to split up the
changes. Two things to watch out for in general are that numpy can be
rather picky about abi compatibility and performance regressions. (The
scalar code is definitely performance-sensitive.)

-n