On Fri, Aug 24, 2018 at 4:00 PM, Stephan Hoyer wrote:
> On Fri, Aug 24, 2018 at 3:14 PM Nathaniel Smith wrote:
>>
>> 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
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 t
> On 29. Aug 2018, at 11:44, Matti Picus 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*th
>> 1. if we do find ourselves in a situation where changing this would
break lots of users, will we consider ourselves beholden to them?
I think that it would be useful for Numpy's continued evolution to develop
the ability to include code on a provisional basis. Other projects do this
and they j
HI All,
On the backwards compatibility: from an astropy perspective, I would expect
that the introduction of `__array_function__` implies a guarantee that the
*functionality* it provides will remain, i.e., that it will continue to be
possible to override, say, concatenate. It is not a big deal if
> On the backwards compatibility: from an astropy perspective, I would
expect that the introduction of `__array_function__` implies a guarantee
that the *functionality* it provides will remain,
My guess is that you wouldn't have this expectation if Numpy released this
feature with explicit "Experi
On Wed, Aug 29, 2018 at 9:53 AM Matthew Rocklin wrote:
> > On the backwards compatibility: from an astropy perspective, I would
> expect that the introduction of `__array_function__` implies a guarantee
> that the *functionality* it provides will remain,
>
> My guess is that you wouldn't have thi
> Well, I guess I'll be proving Nathaniel right: I would *definitely* start
> using __array_function__ in astropy - not being able to concatenate Quantity
> and other instances which use it has been a long-standing pain.
That's fair enough, but I think Matt's point still stands. Any given projec
Absolutely fine to have to deal with future chances - my main point is that
by accepting the NEP, I think numpy is committing to provide some way to
override whatever functions __array_function__ is introduced for, i.e., we
cannot reasonably go back to not providing any way to override such a
funct
On Wed, Aug 29, 2018, 02:44 Matti Picus 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*t
On Wed, Aug 29, 2018 at 9:34 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Absolutely fine to have to deal with future chances - my main point is
> that by accepting the NEP, I think numpy is committing to provide some way
> to override whatever functions __array_function__ is intro
On Wed, Aug 29, 2018 at 1:38 AM Nathaniel Smith wrote:
> The official Tensorflow wheels flat out lie about being manylinux
> compatible, and the Tensorflow team has never talked to anyone about
> how to fix this, they just upload them to PyPI and leave others get to
> deal with the fallout [1]. T
12 matches
Mail list logo
