[Numpy-discussion] numarray unfriendly to user defined types

Fernando Perez fperez at colorado.edu
Mon Sep 22 15:46:13 EDT 2003


Tim Hochberg wrote:

> I agree that using try/except is probably not worth the danger. However, 
> I think I'd prefer the inverse of what you propose. That is:
> 
> 	def __mul__(self, operand):
> 		if isinstance(operand, _numarray_nondeferred_types):
>                         self.__mul__(operand)
> 		else:
> 			operand.__rmul__(self)
> 
> 
> and of course a dont_defer_to registration function. Hopefully with a 
> better name. The choice comes down to whether we defer by default or 
> handle by default. I'm marginally on the side of deferring, but don't 
> feel too strongly either way. Either one would be a big improvement.
> 
> Perhaps someone else out there has some profound thoughts.

Well, certainly not profound, but here's my proverbial $0.02.  I tend to 
really dislike separate registration functions, since they reek too much of 
'programming by side-effect'.  Why not put the necessary information into a 
keyword argument to the constructor?  Once a sensible default is chosen, then 
it can be overridden with 'defers=True' (if the default was False) at __init__ 
time, for example.  Since this is a class-wide issue, perhaps it may make more 
sense to handle it via a meta-class mechanism.  But I'm not an expert on 
metaclasses, so I'll shut up there :)

I know that the above is rather vague, partly because I haven't followed the 
whole thread in detail.  But I hope that my intent, as a design idea, is clear 
(and perhaps even useful :)  While the actual implementation details 
(constructor keyword, metaclass, class-wide global like self.__defers, etc.) 
will have to be settled by the experts, I hope that an approach which doesn't 
rely on separate registration functions can be achieved.

Best regards,

Fernando.





More information about the NumPy-Discussion mailing list