[Numpy-discussion] Prep for NumPy 1.16.0 branch

[Marten van Kerkwijk]

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.harfouche at 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.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
>>
> _______________________________________________
> 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/20181105/805e2c73/attachment.html>