[Numpy-discussion] Prep for NumPy 1.16.0 branch

[Mark Harfouche]

> 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.harris at gmail.com>
wrote:

>
>
> 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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20181104/982ed3e0/attachment.html>