On Wed, Aug 29, 2018, 02:44 Matti Picus <matti.picus@gmail.com> wrote:
On 29/08/18 10:37, Nathaniel Smith wrote:
> it's easy to imagine scenarios where the
> people being broken aren't the ones who had a chance to read the docs
> – e.g. if a major package starts relying on __array_function__, then
> it's all*their*  users who we'd be breaking, even though they had
> nothing to do with it.
This is a packaging problem. This proposal is intended for use by other
"major packages", not so much for end-users. We would have much more
trouble if we were proposing a broad change to something like indexing
or the random number module (see those NEPs). If we break one of those
major packages, it is on them to pin the version of NumPy they can work
with. In my opinion very few end users will be implementing their own
ndarray classes with `__array_function__`. While we will get issue
reports, we can handle them much as we do the MKL or OpenBLAS ones -
pinpoint the problem and urge users to complain to those packages.

Other than adding a warning, I am not sure what the concrete proposal is
here. To not accept the NEP?

The proposal is just that while the NEP is considered experimental and provisional, we should use some kind of technical measures to discourage use in a non-experimental settings. We want to stay in control of when it escapes the lab, and docs alone, or trivially disableable messages, aren't a very effective way to do that.