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

[Stephan Hoyer]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180824/6b98b74f/attachment.html>