[Numpy-discussion] defining a NumPy API standard?

[Hameer Abbasi]

Re: Successful specifications (I’ll avoid using the word standard):

Moving: HTML5/CSS3, C++, Rust, Python, Java.

Static: C

I’d really like this to be a moving spec... A static one is never much use, and is doomed to miss use cases, either today or some from the future.

Best Regards,
Hameer Abbasi

> On Sunday, Jun 02, 2019 at 9:46 AM, Nathaniel Smith <njs at pobox.com (mailto:njs at pobox.com)> wrote:
> On Sat, Jun 1, 2019 at 11:59 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
> > On Sun, Jun 2, 2019 at 12:35 AM Nathaniel Smith <njs at pobox.com> wrote:
> > >
> > > On Sat, Jun 1, 2019 at 1:05 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
> > > > I think this is potentially useful, but *far* more prescriptive and detailed than I had in mind. Both you and Nathaniel seem to have not understood what I mean by "out of scope", so I think that's my fault in not being explicit enough. I *do not* want to prescribe behavior. Instead, a simple yes/no for each function in numpy and method on ndarray.
> > >
> > > So yes/no are the answers. But what's the question?
> > >
> > > "If we were redesigning numpy in a fantasy world without external
> > > constraints or compatibility issues, would we include this function?"
> > > "Is this function well designed?"
> > > "Do we think that supporting this function is necessary to achieve
> > > practical duck-array compatibility?"
> > > "If someone implements this function, should we give them a 'numpy
> > > core compliant!' logo to put on their website?"
> > > "Do we recommend that people use this function in new code?"
> > > "If we were trying to design a minimal set of primitives and implement
> > > the rest of numpy in terms of them, then is this function a good
> > > candidate for a primitive?"
> > >
> > > These are all really different things, and useful for solving
> > > different problems... I feel like you might be lumping them together
> > > some?
> >
> >
> > No, I feel like you just want to see a real proposal. At this point I've gotten some really useful feedback, in particular from Marten (thanks!), and I have a better idea of what to do. So I'll answer a few of your questions, and propose to leave the rest till I actually have some more solid to discuss. That will likely answer many of your questions.
>
> Okay, that's fine. You scared me a bit with the initial email, but I
> really am trying to be helpful :-). I'm not looking for a detailed
> proposal; I'm just super confused right now about what you're trying
> to accomplish or how this table of yes/no values will help do it. I
> look forward to hearing more!
>
> > > I'm seeing this as a living document (a NEP?)
> >
> > NEP would work. Although I'd prefer a way to be able to reference some fixed version of it rather than it being always in flux.
>
> When I say "living" I mean: it would be seen as documenting our
> consensus and necessarily fuzzy rather than normative and precise like
> most NEPs. Maybe this is obvious and not worth mentioning. But I
> wouldn't expect it to change rapidly. Unless our collective opinions
> change rapidly I guess, but that seems unlikely.
>
> (And of course NEPs are in git so we always have the ability to link
> to a point-in-time snapshot if we need to reference something.)
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190602/88e9a141/attachment.html>