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 <n...@pobox.com > (mailto:n...@pobox.com)> wrote: > On Sat, Jun 1, 2019 at 11:59 PM Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > On Sun, Jun 2, 2019 at 12:35 AM Nathaniel Smith <n...@pobox.com> wrote: > > > > > > On Sat, Jun 1, 2019 at 1:05 PM Ralf Gommers <ralf.gomm...@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@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
