[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