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@pobox.com (mailto:njs@pobox.com)> wrote: On Sat, Jun 1, 2019 at 11:59 PM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Jun 2, 2019 at 12:35 AM Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Jun 1, 2019 at 1:05 PM Ralf Gommers <ralf.gommers@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