<div dir="ltr"><div dir="ltr">On Fri, Apr 26, 2019 at 3:10 AM Hameer Abbasi <<a href="mailto:einstein.edison@gmail.com">einstein.edison@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">    <div style="font-family:Helvetica;color:rgb(0,0,0);font-size:13px"><div id="gmail-m_-3576162100779018652CanaryBody"> <div> <div>Here’s how `uarray` solves each of these issues:<br></div><div><div><ol><li>Backends… There is no default implementation.</li><li>This is handled by (thread-safe) context managers, which make switching easy.</li><li>There’s one coercion function per type of objec</li><ul><li>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.</li><li>Conversion can be as simple as lambda x: x.</li><li>There’s a generic dispatcher and reverse dispatcher per function, with “marks” to indicate the type of object.</li></ul><li>Arrays are just one “type” of object you can dispatch over, so there’s no repition by definition.</li></ol></div></div></div></div></div></blockquote><div>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.</div><div><br></div><div>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.</div><div><br></div><div>That said, please save it a separate discussion thread, given that the design of uarray is (wisely) orthogonal to NEP-18.</div></div></div>