[Numpy-discussion] numarray unfriendly to user defined types

[Tim Hochberg]

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
>
>
>
>
>
>  
>