On Tue, Aug 21, 2018 at 6:12 PM, Stephan Hoyer wrote:
> On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith wrote:
>>
>> >> My suggestion: at numpy import time, check for an envvar, like say
>> >> NUMPY_EXPERIMENTAL_ARRAY_FUNCTION=1. If it's not set, then all the
>> >> __array_function__ dispatches
On Tue, Aug 21, 2018 at 9:39 AM, Stephan Hoyer wrote:
> On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith wrote:
>>
>> On Wed, Aug 15, 2018 at 9:45 AM, Stephan Hoyer wrote:
>> > This avoids a classic subclassing problem that has plagued NumPy for
>> > years,
>> > where overriding the behavior of
On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith wrote:
> >> My suggestion: at numpy import time, check for an envvar, like say
> >> NUMPY_EXPERIMENTAL_ARRAY_FUNCTION=1. If it's not set, then all the
> >> __array_function__ dispatches turn into no-ops. This lets interested
> >> downstream
Hi All,
On behalf of the NumPy team, I am pleased to announce the release of NumPy
1.15.1. This is a bugfix release for bugs and regressions reported
following the 1.15.0 release. Noticeable fixes are
- The annoying but harmless RuntimeWarning that "numpy.dtype size
changed" has been
On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith wrote:
> On Wed, Aug 15, 2018 at 9:45 AM, Stephan Hoyer wrote:
> > This avoids a classic subclassing problem that has plagued NumPy for
> years,
> > where overriding the behavior of method A causes apparently unrelated
> method
> > B to break,
I’m +0 on removing it, so mostly neutral, but slightly in favour. While I see
the argument for having it, I also see it as a violation of DRY... The
information is already available in relevant arguments.
I doubt any people implementing this protocol are going to be lazy enough not
to
> >> I don't really understand the 'types' frozenset. The NEP says "it will
> >> be used by most __array_function__ methods, which otherwise would need
> >> to extract this information themselves"... but they still need to
> >> extract the information themselves, because they still have to examine
On Wed, Aug 15, 2018 at 9:45 AM, Stephan Hoyer wrote:
> RE: accidental differences in behavior:
>
> I actually think that the __array_function__ approach is *less* prone to
> accidental differences in behavior, because we require implementing every
> function directly (or it raises an error).
>
>