On Sun, Jun 2, 2019 at 9:46 AM Nathaniel Smith <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!

Thanks! I know this is going to be a little complicated to get everyone on the same page. That's why I'm aiming to get a draft out before SciPy'19 so there's a chance to discuss it in person with everyone who is there. Mailing lists are a poor interface. Will you be at SciPy?


>> 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.

Yeah, I'm going for useful rather than normative:)

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.)

Agreed. One perhaps unintended side effect of separating out the NEPs doc build from the full doc build is that we stopped shipping NEPs with our releases. It would be nicer to say "NEP as of 1.16" rather than "NEP as of commit 1324adf59". Ah well, that's for another time.

Ralf