[Numpy-discussion] numarray unfriendly to user defined types
Todd Miller
jmiller at stsci.edu
Fri Sep 26 11:24:09 CDT 2003
On Fri, 2003-09-26 at 13:31, Colin J. Williams wrote:
> Todd,
>
> This scheme seems rather complex. The purpose isn't clear to me.
>
> What is the problem which this arrangement is intended to solve?
Bottom line, currently:
numarray + another_class --> exception
It would be nice if:
numarray + another_class --> another_class.__radd__(numarray)
Also, look backward at Tim's original post on this subject.
>
> Could I suggest that some scheme along the lines of the Python PEP's be
> used to set out the Why's and Wherefore's?
>
Sounds good for next time.
> It might also be useful to copy this discussion to comp.lang.python as
> that newsgroup has people experienced with classes.
OK, I'll stop being a chicken. Everyone, get ready for the sound of a
pin dropping on c.l.py.
> The problem appears
> to be Python related rather than a problem of numerical analysis.
Yes indeed.
>
> Colin W.
>
> Todd Miller wrote:
>
> >I tried out DeferredToByNumArray yesterday morning and was able to get
> >it to work as planned with numarray and MA. So yay!
> >
> >Yesterday afternoon, I stopped by Perry's office for a final check, and
> >not surprisingly, there are some aspects of this solution that we've
> >overlooked. So not yay!
> >
> >Perry pointed out two ways that the DeferredToByNumArray scheme may fall
> >apart as our inheritance hierarchy becomes richer:
> >
> >1) Imagine not one, but two independent subclasses of NumArray, each of
> >which want NumArray to defer to them. Now imagine them trying to
> >inter-operate with each other. In this case, the meaning of the
> >expression is determined by the order of the operands, so A+B and B+A
> >will either return an A or a B depending on the expression order.
> >
> >2) Imagine again two subclasses of numarray, but this time imagine B as
> >a subclass of A. Here again, both might want to defer to numarray, and
> >again, A+B and B+A return different types driven by the type order of
> >the expression.
> >
> >I don't have a solution yet, but am hopeful that more free candy will
> >fall from the sky... or YAGNI. Perry pointed out that similar problems
> >exist for *any* Python class hierarchy, so we're not alone, and perhaps
> >should forget about this until it matters. If someone sees an easy
> >fix, now would be better than later.
> >
> >Todd
> >On Wed, 2003-09-24 at 19:55, Tim Hochberg wrote:
> >
> >
> >>Todd Miller wrote:
> >>
> >>
> >>
> >>>On Wed, 2003-09-24 at 18:27, Tim Hochberg wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Hi Todd,
> >>>>
> >>>>There are three ways to spell "defer to me" on the table (the precise
> >>>>details of
> >>>>each spelling are, of course, still open for debate):
> >>>>
> >>>> 1. numarray.defer_to(my_class)
> >>>>
> >>>> 2. class ArrayLike(numarray.DeferTo):
> >>>> # ...
> >>>>
> >>>> 3. class ArrayLike:
> >>>> _numarray_defer_to = True
> >>>> # ...
> >>>>
> >>>>I'd prefer a non-registration solution since those are both
> >>>>aesthetically displeasing and leave you open to the situation where a
> >>>>class in module A gets registered by module B, but module C expects it
> >>>>not to be registered and everything breaks. Not all that likely, I
> >>>>admit, but let's avoid the registration version if we can.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I was picturing this as module A registering it's own classes only.
> >>>Nevertheless, inverting the problem and distributing the registration as
> >>>you suggested is better.
> >>>
> >>>
> >>>
> >>>
> >>The case you describe probably will describe the majority of actual use
> >>cases, and in fact describes mine. I'm trying to think ahead a bit to
> >>cases may encounter as start using NumArray more extensively. Let's hope
> >>this solution still looks good in six months!
> >>
> >>
> >>
> >>>>The other two solutions are almost equivalent. The one case where 3 has
> >>>>an edge over 2 is if I have an object (not a class), I could potentially
> >>>>set a _numarray_defer_to on the object before passing it to numarray
> >>>>without having to mess with the class
> >>>>of the object at all. YAGNI, though.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I was more concerned about the potential impact of lots of multiple
> >>>inheritance, but that's probably just my own personal blend of FUD.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>The advantage of 2 in my view is that it *does* force you to subclass.
> >>>>With 3, there will be the temptation to poke into some other module and
> >>>>set _numarray_defer_to on some poor unsuspecting class. This has the
> >>>>same disadvantage as 1, that it could confuse some other poor
> >>>>unsuspecting module. The correct way to do get a deferred class from a
> >>>>third party module is to import and subclass. This works with either 2
> >>>>or 3::
> >>>>
> >>>> import A
> >>>>
> >>>> class Klass2(a.Klass, numarray.DeferTo): #2
> >>>> #...
> >>>>
> >>>> class Klass3(a.Klass): #3 the good way
> >>>> _numarray_defer_to = True
> >>>> # ...
> >>>>
> >>>> A.Klass._numarray_defer_to = True #3 the evil way.
> >>>>
> >>>>Version 2 is cleaner and encourages you to do the right thing, so I'd
> >>>>prefer that solution.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Good enough for me. If no one else has any comments, then
> >>>numarray.DeferTo is where I'll start implementing. Tomorrow.
> >>>
> >>>
> >>>
> >>>
> >>One more minor thing. I'm not sure tha DeferTo is ideal as the mix-in
> >>class name. It was perfect for the registration function name, but I'm
> >>not sure it's so clear whether the class or numarray is being deferred
> >>to when you say numarray.DeferTo. DeferToMe is more descriptive, but
> >>seems sort of slangy. DeferredTo is better than DeferTo, but still not
> >>as descriptive as DeferToMe. numarray.DefersTo reads perfect as long as
> >>numarray is included but is a disaster if you read it on your own.
> >>Below I've put down all the ideas I could come up with
> >>
> >>class CustomArray(numarray.DeferTo)
> >>class CustomArray(numarray.DefersTo)
> >>class CustomArray(numarray.DeferredTo)
> >>class CustomArray(numarray.DeferToMe)
> >>class CustomArray(numarray.DeferredToByNumarray)
> >>class CustomArray(DeferTo)
> >>class CustomArray(DefersTo)
> >>class CustomArray(DeferredTo)
> >>class CustomArray(DeferToMe)
> >>class CustomArray(DeferredToByNumarray)
> >>
> >>For me it's a toss up between DefferedTo, DeferToMe and
> >>DeferredToByNumarray. The first is a little lacking in descriptive
> >>power, the second is slangy and the third is wordy.
> >>
> >>-tim
> >>
> >>[not that this matters much....]
> >>
> >>
> >>
> >>
> >>>>regards,
> >>>>
> >>>>-tim
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Thanks again,
> >>>Todd
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Numpy-discussion mailing list
> >>Numpy-discussion at lists.sourceforge.net
> >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >>
> >>
>
>
--
Todd Miller jmiller at stsci.edu
STSCI / ESS / SSB
More information about the Numpy-discussion
mailing list