[Numpy-discussion] Extent to which to work around matrix and other duck/subclass limitations

[Charles R Harris]

On Thu, Jun 13, 2019 at 6:21 PM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

> Hi Ralf,
>
> Thanks both for the reply and sharing the link. I recognize much (from
> both sides!).
>
> <snip>
>
>>
>> More importantly, I think we should not even consider *discussing*
>> removing` __array_function__` from np.isposinf (or any similar one off
>> situation) before there's a new bigger picture design. This is not about
>> "deprecation is hard", this is about doing things with purpose rather than
>> ad-hoc, as well as recognizing that lots of small changes are a major drain
>> on our limited maintainer resources. About the latter issue I wrote a blog
>> post recently, perhaps that clarifies the previous sentence a bit and gives
>> some more insight in my perspective:
>> https://rgommers.github.io/2019/06/the-cost-of-an-open-source-contribution/
>>
>> Yes, I definitely did not mean to imply that a goal was to change just
> `isposinf`, `sum`, or `nansum` (the goal of the PR that started this thread
> was to clean up the whole `nanfunctions` module). Rather, to use them as
> examples to see what policy there actually is or should be; and I do worry
> that with __array_function__, however happy I am that it now exists
> (finally, Quantity can be concatenated!), we're going the Microsoft route
> of just layering on top of old code if even for the simplest cases there is
> no obvious path for how to remove it.
>
> Anyway, this discussion is probably gotten beyond the point where much is
> added. I'll close the `nansum` PR.
>
> All the best,
>
> Marten
>
>
> p.s. I would say that deprecations within numpy currently *are* hard.
> E.g., the rate at which we add `DEPRECATED` to the C code is substantially
> larger than that with which we actually remove any long-deprecated
> behaviour.
>
>

That's been true for the last couple of releases, but not historically. The
main problem was lack of time compounded by a  FutureWarning that got stuck
because it broke code in unexpected ways when brought to fruition. For 1.16
I decided that expiring spent deprecations wasn't worth the churn. At this
point I see 1.18 as the release that starts the cleanup, and possibly the
start of removing the Python 2.7 compatibility code.

Speaking of 1.18, the other thing I'd like to see is discussion of a masked
array replacement. I think the basic infrastructure is now in place for
that. Hmm... should probably make a separate post eliciting ideas for 1.18.

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