On Fri, Apr 26, 2019 at 3:10 AM Hameer Abbasi <einstein.edi...@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.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
