<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 6, 2019 at 5:16 PM Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 6, 2019 at 11:44 AM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Fri, Sep 6, 2019 at 1:32 AM Hameer Abbasi <<a href="mailto:einstein.edison@gmail.com" target="_blank">einstein.edison@gmail.com</a>> wrote:<br>
>><br>
>> That's a lot of very good questions! Let me see if I can answer them one-by-one.<br>
>><br>
>> On 06.09.19 09:49, Nathaniel Smith wrote:<br>
>><br>
>> But even that could be accomplished by just<br>
>> putting something in the docs. And adding the alias has substantial<br>
>> risks: it makes unumpy tied to the numpy release cycle and<br>
>> compatibility rules, and it means that we're committing to maintaining<br>
>> unumpy ~forever even if Hameer or Quansight move onto other things.<br>
>> That seems like a lot to take on for such vague benefits?<br>
>><br>
>> 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).<br>
><br>
><br>
> Let me address this separately, since it's not really a technical concern.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Third, unumpy is a fairly thin layer over uarray, which already has another user in SciPy.<br>
<br>
I'm sorry if that came across as some kind snipe at Quansight<br>
specifically. I didn't mean it that way. It's a much more general<br>
concern: software projects are inherently risky, and often fail;<br>
companies and research labs change focus and funding shifts around.<br>
This is just a general risk that we need to take that into account<br>
when making decisions. And when there are proposals to add new<br>
submodules to numpy, we always put them under intense scrutiny,<br>
exactly because of the support commitments.<br></blockquote><div><br></div><div>Yes, that's fair, and we should be critical here. All code we accept is indeed a maintenance burden.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The new fft and random code are replacing/extending our existing<br>
public APIs that we already committed to, so that's a very different<br>
situation. And __array_function__ was something that couldn't work at<br>
all without being built into numpy, and even then it was controversial<br>
and merged on an experimental basis. It's always about trade-offs. My<br>
concern here is that the NEP is proposing that the numpy maintainers<br>
take on this large commitment,</blockquote><div><br></div><div>Again, not just the NumPy maintainers. There really isn't that much in `unumpy` that's all that complicated. And again, `uarray` has multiple maintainers (note that Peter is also a SciPy core dev) and has another user in SciPy.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> *and* AFAICT there's no compensating<br>
benefit to justify that: everything that can be done with<br>
numpy.overridable can be done just as well with a standalone unumpy<br>
package... right?<br></blockquote><div><br></div><div>True, mostly. But at that point, if we say that it's the way to do array coercion, and creation (and perhaps some other things as well), we're saying at the same time that every other package that needs this (e.g. Dask, CuPy) should take unumpy as a hard dependency. Which is a much bigger ask than when it comes with NumPy. We can discuss it of course.</div><div><br></div><div>Major exception is if we want to make it default for some functionality, like for example numpy.fft (I'll answer your other email for that.</div><div><br></div><div>Cheers,<br></div><div>Ralf<br></div></div></div>