Hey Blake, 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"
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. 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. 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). 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: http://alexgaynor.net/2010/jun/26/multimethods-python/ https://pypi.python.org/pypi/typed.py 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. Best regards, -Travis On Wed, Jul 10, 2013 at 10:29 PM, Blake Griffith <[email protected] > wrote: > Hello NumPy, > > 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. > > 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: > http://cwl.cx/posts/week-6-ufunc-overrides.html > This is similar to a previously discussed, but never implemented change: > http://mail.scipy.org/pipermail/numpy-discussion/2011-June/056945.html > > However it seems like the ufunc machinery might be ripped out and replaced > with a true multi-method implementation soon. See Travis' blog post: > > http://technicaldiscovery.blogspot.com/2013/07/thoughts-after-scipy-2013-and-specific.html > 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? > > Until then, I'm writing up a nep, it is still pretty incomplete, it can be > found here: > > https://github.com/cowlicks/numpy/blob/ufunc-override/doc/neps/ufunc-overrides.rst > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- Travis Oliphant Continuum Analytics, Inc. http://www.continuum.io
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
