<div dir="ltr">Hey Blake, <div><br></div><div style>To be clear, my blog-post is just a pre-NEP and should not be perceived as something that will transpire in NumPy anytime soon.    You should take it as a "hey everyone, I think I know how to solve this problem, but I have no time to do it, but wanted to get the word out to those who might have the time"  </div>
<div style><br></div><div style>I think the multi-method approach I outline is the *right* thing to do for NumPy.   Another attribute on ufuncs would be a bit of a hack (though easier to implement).   But, on the other-hand, the current ufunc attributes are also a bit of a hack. </div>
<div style><br></div><div style>While my overall proposal is to make *all* functions in NumPy (and SciPy and Scikits) multimethods, I think it's actually pretty straightforward and a more contained problem to make all *ufuncs* multi-methods.   I think that could fit in a summer of code project. </div>
<div style><br></div><div style>I don't think it would be that difficult to make all ufuncs multi-methods that dispatch based on the Python type (they are already multi-methods based on the array dtype).    You could basically take the code from Guido's essay or from Peak Rules multi-method implementation or from the links below and integrate it with a wrapped version of the current ufuncs (or do a bit more glue and modify the ufunc_call function in 'C' directly and get nice general multi-methods for ufuncs).</div>
<div style><br></div><div style>Of course, you would need to define a decorator that NumPy users could use to register their multi-method implementation with the ufunc.   But, this again would not be too difficult.      Look for examples and inspiration at the following places: </div>
<div style><br></div><div style><a href="http://alexgaynor.net/2010/jun/26/multimethods-python/">http://alexgaynor.net/2010/jun/26/multimethods-python/</a><br></div><div style><a href="https://pypi.python.org/pypi/typed.py">https://pypi.python.org/pypi/typed.py</a><br>
</div><div style><br></div><div style>I really think this would be a great addition to NumPy (it would simplify a lot of cruft around masked arrays, character arrays, etc.) and be quite useful.   I wish you the best.     I can't promise I will have time to help, but I will try to chime in the best I can. </div>
<div style><br></div><div style>Best regards,</div><div style><br></div><div style>-Travis</div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 10:29 PM, Blake Griffith <span dir="ltr"><<a href="mailto:blake.a.griffith@gmail.com" target="_blank">blake.a.griffith@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello NumPy,<div><br>Part of my GSoC is compatibility with SciPy's sparse matrices and NumPy's ufuncs. Currently there is no feasible way to do this without changing ufuncs a bit. </div>
<div><br></div>
<div>I've been considering a mechanism to override ufuncs based on checking the ufuncs arguments for a __ufunc_override__ attribute. Then handing off the operation to a function specified by that attribute. I prototyped this in python and did a demo in a blog post here:</div>

<div><a href="http://cwl.cx/posts/week-6-ufunc-overrides.html" target="_blank">http://cwl.cx/posts/week-6-ufunc-overrides.html</a><br></div><div>This is similar to a previously discussed, but never implemented change:<br>
</div><div><a href="http://mail.scipy.org/pipermail/numpy-discussion/2011-June/056945.html" target="_blank">http://mail.scipy.org/pipermail/numpy-discussion/2011-June/056945.html</a></div>
<div><br></div><div>However it seems like the ufunc machinery might be ripped out and replaced with a true multi-method implementation soon. See Travis' blog post:</div><div><a href="http://technicaldiscovery.blogspot.com/2013/07/thoughts-after-scipy-2013-and-specific.html" target="_blank">http://technicaldiscovery.blogspot.com/2013/07/thoughts-after-scipy-2013-and-specific.html</a><br>

</div><div>So I'd like to make my changes as forward compatible as possible. However I'm not sure what I should even consider here, or how forward compatible my current implementation is. Thoughts?</div><div><br>
</div>
<div>Until then, I'm writing up a nep, it is still pretty incomplete, it can be found here:</div><div> <a href="https://github.com/cowlicks/numpy/blob/ufunc-override/doc/neps/ufunc-overrides.rst" target="_blank">https://github.com/cowlicks/numpy/blob/ufunc-override/doc/neps/ufunc-overrides.rst</a></div>

</div>
<br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><br><div>Travis Oliphant</div><div>Continuum Analytics, Inc.<br></div><div><a href="http://www.continuum.io" target="_blank">http://www.continuum.io</a></div>
</div>
</div>