[Numpy-discussion] Prep for NumPy 1.16.0 branch

[Charles R Harris]

On Sun, Nov 4, 2018 at 6:16 PM Stephan Hoyer <shoyer at gmail.com> wrote:

> On Sun, Nov 4, 2018 at 10:32 AM Marten van Kerkwijk <
> m.h.vankerkwijk at gmail.com> wrote:
>
>> Hi Chuck,
>>
>> For `__array_function__`, there was some discussion in
>> https://github.com/numpy/numpy/issues/12225 that for 1.16 we might want
>> to follow after all Nathaniel's suggestion of using an environment variable
>> or so to opt in (since introspection breaks on python2 with our wrapped
>> implementations).  Given also the possibly significant hit in performance,
>> this may be the best option.
>> All the best,
>>
>> Marten
>>
>
> I am also leaning towards this right now, depending on how long we plan to
> wait for releasing 1.16. It will take us at least a little while to sort
> out performance issues for __array_function__, I'd guess at least a few
> weeks. Then a blocker still might turn up during the release candidate
> process (though I think we've found most of the major bugs / downstream
> issues already through tests on NumPy's dev branch).
>

My tentative schedule is to branch in about two weeks, then allow 2 weeks
of testing for rc1, possibly another two weeks for rc2, and then a final.
so possibly about six weeks to final release. That leaves 2 to 4 weeks of
slack before 2019.


> Overall, it does feels a little misguided to rush in a change as pervasive
> as __array_function__ for a long term support release. If we exclude
> __array_function__ I expect the whole release process for 1.16 would go
> much smoother. We might even try to get 1.17 out faster than usual, so we
> can minimize the number of additional changes besides __array_function__
> and going Python 3 only -- that's already a good bit of change.
>

I would like to get 1.17 out a bit early. I'm not sure how many backwards
incompatible changes we want to have in the first post python2 release. My
initial thoughts are to drop Python 2.7 testing, go to C99, and get the new
fft in. Beyond that, I'm hesitant to start tearing out all the Python2
special casing in the first new release, although that could certainly be
the main task for 1.17 and would clean up the code considerably. It might
also be a good time to catch up on changing deprecations to errors.
Thoughts on how to proceed are welcome.


> Note that if we make this change (reverting __array_function__), we'll
> need to revisit where we put a few deprecation warnings -- these will need
> to be restored into function bodies, not their dispatcher functions.
>
> Also: it would be really nice if we get matmul-as-ufunc in before (or at
> the same time) as __array_function__, so we have a complete story about it
> being possible to override everything in NumPy. This is another argument
> for delaying __array_function__, if matmul-as-ufunc can't make it in time
> for 1.16.
>

That's two votes for matmul-as-ufunc. How much would it cost to simply make
__array_function__ a nop?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20181104/da4a1c3e/attachment-0001.html>