[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
--
Todd Miller <jmiller at stsci.edu>
More information about the NumPy-Discussion
mailing list