[Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

Nathaniel Smith njs at pobox.com
Fri Sep 6 20:16:04 EDT 2019


On Fri, Sep 6, 2019 at 11:44 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>
>
> On Fri, Sep 6, 2019 at 1:32 AM Hameer Abbasi <einstein.edison at gmail.com> wrote:
>>
>> That's a lot of very good questions! Let me see if I can answer them one-by-one.
>>
>> On 06.09.19 09:49, Nathaniel Smith wrote:
>>
>> But even that could be accomplished by just
>> putting something in the docs. And adding the alias has substantial
>> risks: it makes unumpy tied to the numpy release cycle and
>> compatibility rules, and it means that we're committing to maintaining
>> unumpy ~forever even if Hameer or Quansight move onto other things.
>> That seems like a lot to take on for such vague benefits?
>>
>> I can assure you Travis has had the goal of "replatforming SciPy" from as far back as I met him, he's spawned quite a few efforts in that direction along with others from Quansight (and they've led to nice projects). Quansight, as I see it, is unlikely to abandon something like this if it becomes successful (and acceptance of this NEP will be a huge success story).
>
>
> Let me address this separately, since it's not really a technical concern.
>
> First, this is not what we say for other contributions. E.g. we didn't say no to Pocketfft because Martin Reineck may move on, or __array_function__ because Stephan may get other interests at some point, or a whole new numpy.random, etc.
>
> Second, this is not about Quansight. At Quansight Labs we've been able to create time for Hameer to build this, and me and others to contribute - which is very nice, but the two are not tied inextricably together. In the end it's still individuals submitting this NEP. I have been a NumPy dev for ~10 years before joining Quansight, and my future NumPy contributions are not dependent on staying at Quansight (not that I plan to go anywhere!). I'm guessing the same is true for others.
>
> Third, unumpy is a fairly thin layer over uarray, which already has another user in SciPy.

I'm sorry if that came across as some kind snipe at Quansight
specifically. I didn't mean it that way. It's a much more general
concern: software projects are inherently risky, and often fail;
companies and research labs change focus and funding shifts around.
This is just a general risk that we need to take that into account
when making decisions. And when there are proposals to add new
submodules to numpy, we always put them under intense scrutiny,
exactly because of the support commitments.

The new fft and random code are replacing/extending our existing
public APIs that we already committed to, so that's a very different
situation. And __array_function__ was something that couldn't work at
all without being built into numpy, and even then it was controversial
and merged on an experimental basis. It's always about trade-offs. My
concern here is that the NEP is proposing that the numpy maintainers
take on this large commitment, *and* AFAICT there's no compensating
benefit to justify that: everything that can be done with
numpy.overridable can be done just as well with a standalone unumpy
package... right?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org


More information about the NumPy-Discussion mailing list