On Fri, Apr 26, 2019 at 3:10 AM Hameer Abbasi <einstein.edison@gmail.com> wrote:

Here’s how `uarray` solves each of these issues:

- Backends… There is no default implementation.
- This is handled by (thread-safe) context managers, which make switching easy.
- There’s one coercion function per type of objec

- Libraries are only asked to dispatch over objects they know how to convert, so there’s no backwards-incompatible break when we add dtypes or ufuncs.
- Conversion can be as simple as lambda x: x.
- There’s a generic dispatcher and reverse dispatcher per function, with “marks” to indicate the type of object.
- Arrays are just one “type” of object you can dispatch over, so there’s no repition by definition.

Hameer, it's great that you are exploring these problems with a fresh approach! I'm excited to see how dispatching problems could be solved without the constraint of compatibility with NumPy's legacy approaches.

When you have a prototype and/or design documents ready for review, please do share them with the numpy-discussion list. I would be very glad to review them and share my perspective.

That said, please save it a separate discussion thread, given that the design of uarray is (wisely) orthogonal to NEP-18.