On Nov 18, 2016 3:30 PM, "Ralf Gommers" <ralf.gomm...@gmail.com> wrote: > > > > On Sat, Nov 19, 2016 at 5:24 AM, Nathaniel Smith <n...@pobox.com> wrote: >> >> Another thing to think about is that 1.12 on pypy won't pass its test suite (though it's close), and we're not yet testing new PRs on pypy, so no guarantees about 1.13 yet. I think on balance these probably aren't reasons *not* to upload wheels, but it's a funny place where we're talking about providing "official" builds even though it's not an "officially supported platform". So we will at least want to be clear about that. And someone will have to handle the bug reports about the test suite failing :-). > > > Those are good points. We could run PyPy on TravisCI; the PyPy install and numpy build aren't difficult anymore.
I'm not sure how useful this until the test suite is passing, though, just because of how travis-ci works. The main outstanding issue needs some work on the numpy side: basically UPDATEIFCOPY, as currently conceived, just can't work reliably on pypy, because it assumes that Python objects get deterministically deallocated as soon as their reference count drops to zero, and pypy doesn't have reference counts. I think fixing this should be straightforward enough, in case anyone wants to work on it. Every user of UPDATEIFCOPY already has to be aware of the reference counts and know when the pseudo-"view" array is supposed to be deallocated. So I think we should define a new UPDATEIFCOPY2 flag, which acts like the current UPDATEIFCOPY, except that instead of using __del__ to do the writeback, there's an explicit API call you have to make, like PyArray_UpdateIfCopy2_Writeback, that checks for the flag and does the writeback if set. Then we should transition to using this internally, and probably deprecate UPDATEIFCOPY (though we may never be able to get rid of it entirely). -n
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
