[Numpy-discussion] numarray unfriendly to user defined types

Todd Miller jmiller at stsci.edu
Tue Sep 23 04:01:10 EDT 2003

On Mon, 2003-09-22 at 19:41, Fernando Perez wrote:
> Tim Hochberg wrote:
> > I actually have no idea how you plan to make keyword arguments work 
> > here, perhaps you could explain that in more detail. Metaclasses are 
> > overkill, but a mixin, marker class could be used. That is, when 
> > designing a class for use with numarray, one would derive a class from a 
> > marker class in numarray::
> Well, the joys of being vague :)  As I said, I haven't followed in enough 
> detail to be too specific, so perhaps my idea plain doesn't work.  But what I 
> had in mind was something along the lines of:
> class ArrayLike(numarray):
> 	def __init__(self,...):
> 		...
> 		numarray.__init__(defers=1)

I think this behavior is already granted by Python at the abstract
object level;  that is, if you subclass, the r-method of the subclass is
given preference over the l-method of the superclass.  That's my
impression anyway.

Thus, I think we already get "deference" for free with subclasses, but
that is too weak in general because often (like MA for instance) people
won't want to subclass from NumArray.

> This is ultimately equivalent to a registration process, but since it is done 
> in the constructor, it feels less like a separate dangling side-effect.  On 
> the other hand, it makes your new constructor more expensive, and it feels 
> ugly to be doing at the instance level things which truly belong at the class 
> level.  Hence my comment about this perhaps being better done via metaclasses.
> As I said, I knew I was being vague.  But hopefully these comments at least 
> suggest a way out of a separate registration step.

They certainly appear to have done so.  Thanks for commenting.


Todd Miller <jmiller at stsci.edu>

More information about the NumPy-Discussion mailing list