Hi,

I verified that this version of PyPy can load a Numpy array that was pickled by CPython (and do stuff with it), but it looks like a Numpy array pickled by PyPy cannot be loaded by CPython, because PyPy still uses  '_numpypy.multiarray' in the pickle string for dumping:
ImportError: No module named _numpypy.multiarray

David.

On Sat, Jul 16, 2016 at 12:07 PM, Matti Picus <matti.picus@gmail.com> wrote:
The issue with '_numpypy.multiarray' in the pickle string rather than 'numpy.core.multiarray' should be fixed on the numpypy_pickle_compat branch (thanks to Eli)
A linux 64 build is available http://buildbot.pypy.org/nightly/numpypy_pickle_compat/pypy-c-jit-85727-6d909c810029-linux64.tar.bz2.
Eli or David or anyone who uses numpy pickle, could you check that this works as advertised? I am concerned about how compatible our pickling is with upstream numpy, but do not really use that feature of numpy so another pair of eyes would be nice before merging to default.

Note this requires that http://bitbucket.org/pypy/numpy be installed since the Unpickler must be able to import numpy.core.multiarray
Matti

On 15/07/16 10:47, David Brochart wrote:
Hi,

I'd like to use the (numerical) performances of PyPy as an equivalent to Numba's @jit decorator (https://github.com/davidbrochart/piopio). The only thing preventing that right now is the passing around (pickling) of Numpy arrays, so it would be great to have that compatibility.

David.

 On Mon, Jul 11, 2016 at 6:43 PM, Eli Stevens (Gmail) <wickedgrey@gmail.com <mailto:wickedgrey@gmail.com>> wrote:

    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 <arigo@tunes.org
     <mailto:arigo@tunes.org>> wrote:
    > Hi Eli, hi Matti,
    >
    > On 29 June 2016 at 21:37, Eli Stevens (Gmail)
     <wickedgrey@gmail.com <mailto:wickedgrey@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 <mailto:pypy-dev@python.org>
    https://mail.python.org/mailman/listinfo/pypy-dev




_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev