For astropy, we also waiting a little before having a rip-python2-out fiesta.
I think it is worth trying to get matmul in 1.16, independently of __array_function__ - it really belongs to ufunc overwrites and all the groundwork has been done. For __array_function__, is it at all an option to go to the disable-by-default step? I.e., by default have array_function_dispatch just return the implementation instead of wrapping it? Though perhaps reversion is indeed cleaner; most people who would like to play with it are quite able to install the development version... -- Marten On Sun, Nov 4, 2018 at 10:43 PM Mark Harfouche <mark.harfou...@gmail.com> wrote: > > Thoughts on how to proceed are welcome. > > I've been involved in scikit-image and that project tore out the python2 > only code rather quickly after 2.7 support was dropped. I think it caused a > few hiccups when backporting bugfixes. I imagine that `1.16.1` and `1.16.2` > releases will come out quickly and as such, I think removing `if else` > statements for python2 immediately after `1.16` is released will cause > annoyances in the first few months bugs are being ironed out. > > My 2cents. > > On Sun, Nov 4, 2018 at 10:04 PM Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Sun, Nov 4, 2018 at 6:16 PM Stephan Hoyer <sho...@gmail.com> wrote: >> >>> On Sun, Nov 4, 2018 at 10:32 AM Marten van Kerkwijk < >>> m.h.vankerkw...@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 >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
