FWVLIW, I think that conforming to upstream numpy makes the most sense. I think that the issue would go away if the `_numpypy` module were renamed to `numpy` (and appropriate things moved into `numpy.core`). Is there a technical reason to keep the actual implementation in a separately named module?
Thinking larger picture, would it be possible and sensible to switch to using the slow cpyext numpy approach for compatability, then overlay custom implementation of things on top of that when speed is needed? I'm imagining a vague inverse of the cpython approach, where modules are implemented in C when the python performance isn't acceptable. Eli On Wed, Jun 29, 2016 at 10:58 PM, Armin Rigo <ar...@tunes.org> wrote: > Hi Eli, hi Matti, > > On 29 June 2016 at 21:37, Eli Stevens (Gmail) <wickedg...@gmail.com> wrote: >> To make sure I'm understanding, are you saying that upstream/cpython >> numpy should pick up an alternate way to import multiarray (via >> _numpypy.multiarray, instead of numpy.core.multiarray) > > Hum, in my opinion we should always pickle/unpickle arrays by > reproducing and expecting the exact same format as CPython's numpy, > with no warnings. Any difference (e.g. with complicated dtypes) is a > bug that should eventually be fixed. > > > A bientôt, > > Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
