Hi Sebastian, Thanks for your reply!
2010/9/22 Sebastian Walter <sebastian.wal...@gmail.com>: > [...] I think the issue is not so much numpy but rather the > way Python implements operator overloading using methods like __add__ > and __radd__. Hence, your suggestion seems to be a Python Enhancement > Proposal and should be discussed without any references to numpy or > bugs related to numpy.set_numeric_ops. Yeah, I agree, but i refrained from spamming the list with two separate mails, although I see now it would have been better, and would have brought more eyes on it. For the PEP, I will look into this and will check the mailing lists. For the technical things, I think the implementation of the operations must lie in the classes, and thus __add__ etc. are in principle okay. But as described in the new README, there is need to organise this functions. priop (note the rename, "priops" turned out to be always spelled "priop" in the source code) could define this new layer. > Maybe you could also have a look at Go's interfaces (Googles > programming language) which seems to be somewhat related to your > approach. I will try. Can you provide an URL? > On a more practical note: Why exactly do you use set_numeric_ops? You > could also > 1) use numpy.ndarrays with dtype=object This is too slow. And it's eating up memory because of the Python objects stored with all their bells and whistles. > 2) or create new numpy.ndarray -like class and set __array_priority__ > 2 > both approaches work well for me. I wanted to avoid exactly this because I think priop is a better approach, via set_numeric_ops(). The new URL is: http://github.com/friedrichromstedt/priop (just for the rename, which may be discussable). It contains now also an implementation, which was much less hard than expected ... Friedrich _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion