<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 4, 2018 at 6:16 PM Stephan Hoyer <<a href="mailto:shoyer@gmail.com">shoyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Nov 4, 2018 at 10:32 AM Marten van Kerkwijk <<a href="mailto:m.h.vankerkwijk@gmail.com" target="_blank">m.h.vankerkwijk@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi Chuck,</div><div><br></div><div>For `__array_function__`, there was some discussion in <a href="https://github.com/numpy/numpy/issues/12225" target="_blank">https://github.com/numpy/numpy/issues/12225</a> 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.<br></div></div><div></div><div>All the best,</div><div><br></div><div>Marten</div></div></blockquote><div><br></div><div>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).</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>That's two votes for matmul-as-ufunc. How much would it cost to simply make __array_function__ a nop?</div><div><br></div><div>Chuck </div></div></div>