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), similar to how one can `import numpy` under pypy, even though the real implementation is in `_numpypy`?
Thanks, Eli On Wed, Jun 29, 2016 at 11:31 AM, Matti Picus <matti.pi...@gmail.com> wrote: > I think I would prefer this be done in upstream numpy (which is 95% > supported by PyPy's cpyext layer) rather than changing the class name when > saving a _numpypy ndarray. In both cases, a warning should be emitted when > loading the "wrong" object to tell the user that subtle problems may occur, > for instance with complicated record dtypes or with arrays of objects. > > Your pull request seems OK, it needs tests of more complicated numpy types > like scalars and record arrays. Again, I would be happier if it spit out > some kind of warning when overriding the object name. > Maybe we should merge it until we can fix upstream numpy? > Does anyone else have an opinion? > Matti > > On 29/06/16 19:59, Eli Stevens (Gmail) wrote: >> >> Any thoughts on if this approach is acceptable? Happy to incorporate >> feedback. >> >> I wouldn't be surprised if there are more functions than just >> _reconstruct that will need to be special cased, but without a >> concrete use case I wasn't going to complicate things. >> >> Thanks, >> Eli >> >> > > _______________________________________________ > pypy-dev mailing list > 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
