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:
  1. Backends… There is no default implementation.
  2. This is handled by (thread-safe) context managers, which make switching easy.
  3. 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.
  4. 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.