On 1/6/19 7:31 pm, Charles R Harris wrote:
I generally agree with this. The most useful aspect of this exercise is likely to be clarifying NumPy for its own developers, and maybe offering a guide to future simplification. Trying to put something together that everyone agrees to as an official standard would be a big project and, as Nathaniel points out, would involve an enormous amount of work, much time, and doubtless many arguments. What might be a less ambitious exercise would be identifying commonalities in the current numpy-like languages. That would have the advantage of feedback from actual user experience, and would be more like a lessons learned document that would be helpful to others.
More concretely, to address Nathaniel's (very reasonable) worry about ending up wasting a lot of time, I think it may be good to identify smaller parts, each of which are useful on their own.
In this respect, I think an excellent place to start might be something you are planning already anyway: update the user documentation
I would include tests as well. Rather than hammer out a full standard based on extensive discussions and negotiations, I would suggest NumPy might be able set a de-facto "standard" based on pieces of the the current numpy user documentation and test suite. Then other projects could use "passing the tests" as an indication that they implement the NumPy API, and could refer to the documentation where appropriate. Once we have a base repo under numpy with tests and documentations for the generally accepted baseline interfaces. we can discuss on a case-by-case basis via pull requests and issues whether other interfaces should be included. If we find general classes of similarity that can be concisely described but not all duckarray packages support (structured arrays, for instance), these could become test-specifiers `@pytest.skipif(not HAVE_STRUCTURED_ARRAYS)`, the tests and documentation would only apply if that specifier exists. Matti