On Wed, Aug 29, 2018, 02:44 Matti Picus <matti.pi...@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. -n >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
