[Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

[einstein.edison at gmail.com]

> I’m On 25. Aug 2018, at 00:13, Nathaniel Smith <njs at pobox.com> wrote:
> 
>> On Fri, Aug 24, 2018 at 1:46 PM, Stephan Hoyer <shoyer at gmail.com> wrote:
>> On Fri, Aug 24, 2018 at 1:36 AM Hameer Abbasi <einstein.edison at gmail.com>
>> wrote:
>>> 
>>> 
>>>> On Fri, Aug 24, 2018 at 9:38 AM Nathaniel Smith <njs at pobox.com> wrote:
>>>> 
>>>>> On Thu, Aug 23, 2018 at 9:02 AM,  <einstein.edison at gmail.com> wrote:
>>>>> I might add that most duck array authors are highly unlikely to be
>>>>> newcomers
>>>>> to the Python space. We should just put a big warning there while
>>>>> enabling
>>>>> and that’ll be enough to scare away most devs from doing it by default.
>>>> 
>>>> That's a reasonable idea... a Big Obnoxious Warning(tm) when it's
>>>> enabled, or on first use, would achieve a lot of the same purpose.
>>>> E.g.
>>>> 
>>>> if this_is_the_first_array_function_usage():
>>>>    sys.stderr.write(
>>>>        "WARNING: this program uses NumPy's experimental
>>>> '__array_function__' feature.\n"
>>>>        "It may change or be removed without warning, which might
>>>> break this program.\n"
>>>>        "For details see
>>>> http://www.numpy.org/neps/nep-0018-array-function-protocol.html\n"
>>>>    )
>>>> 
>>>> -n
>>>> 
>>> 
>>> I was thinking of a FutureWarning... That's essentially what it's for.
>>> Writing to stderr looks un-pythonic to me.
>> 
>> 
>> Issuing a FutureWarning seems roughly appropriate here. The Python 3.7 docs
>> write:
>> "Base category for warnings about deprecated features when those warnings
>> are intended for end users of applications that are written in Python."
>> 
>> Writing to sys.stderr directly is generally considered poor practice for a
>> Python libraries.
>> 
>> In my experience FutureWarning does a good job of satisfying the goals of
>> being a "Big Obnoxious Warning" while still being silence-able and testable
>> with standard tools.
> 
> Yeah, the reason warnings are normally recommended is because
> normally, you want to make it easy to silence. But this is the rare
> case where I didn't want to make it easy to silence, so I didn't
> suggest using a warning :-).

I really doubt anyone is going to silence a FutureWarning and then come complaining that a feature was removed.

> 
> Calling warnings.warn (or the C equivalent) is also very expensive,
> even if the warning ultimately isn't displayed. I guess we could do
> our own tracking of whether we've displayed the warning yet, and only
> even attempt to issue it once, but that partially defeats the purpose
> of using warnings in the first place.

How about calling it at enable-time once? That’s why I suggested that in the first place.

> 
> -n
> 
> -- 
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

Best regards,
Hameer Abbasi
Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180825/ebbd2122/attachment.html>