[Numpy-discussion] Ransom Proposals

[Travis Oliphant]

Tim Hochberg wrote:

> Travis Oliphant wrote:
>
>> Tim Hochberg wrote:
>>
>>>>
>>>> Yes, having this ability means that you have to think about it a 
>>>> bit if you are going to use the functional interface and try to do 
>>>> in-place operations.  But, I would argue that this is an "advanced" 
>>>> usage which is implemented to save space and time.
>>>
>>>
>>>
>>>
>>> How is this true though? In what way, for instance, is:
>>>
>>>    b = asarray(a).reshape(newshape)
>>>
>>> slower or less space efficient than todays:
>>>
>>>    b = reshape(a)
>>
>>
>>
>>
>> Well, the big difference is that b=reshape(a) is actually
>>
>> try:
>>     reshape = a.reshape
>> except AttributeError:
>>     return a.__array_wrap__(asarray(a).reshape(newshape))
>>
>> return reshape(newshape)
>>
>> So, it handles more cases, more cleanly then the 
>> asarray(a).rehsape(newshape) approach does.
>
>
> OK. Although I should have said asanyarray(a).reshape(newshape),  I 
> still see how that this handles more cases. 

Because you can define objects that aren't sub-classes of the array at 
all but just define the method reshape and still have the functional 
interface work.

>
> I need to go think about this case some more. This is not something 
> that I've run into in practice, but I can see I'll have a stronger 
> case if I can come up with a alternative to this in terms of safe 
> functions. Do you have some examples of objects that do not have 
> 'reshape', but do have '__array_wrap__'?


Not presently, the __array_wrap__ method is new.  It's a mechanism for 
letting functions that need arrays internally to be more polymorphic and 
deal with different kinds of objects.


It would seem that most of Tim's complaints are directly against 
polymorphism.   I would argue that getting rid of polymorphism is not 
something we should be trying to do in NumPy.


Tim is pointing out that if you use polymorphic functions then you can't 
assume things like "in-place" have any meaning.  But, then Python has 
this same problem, because

l += a

doesn't do 'in-place' for the list, but does do inplace if 'l' were an 
array.   In my mind, this problem and Tim's concern over 'view' and 
'copy' behavior is one and the same.   I don't view it as a problem of 
function behavior as much as problem with documentation and "mismatch 
between what a particular user expects and what is actually done."

My attitude is that to write 'in-place' functions (what seems to be the 
driving example that Tim brings up), you need to know some details about 
what kind of object you are dealing with anyway, so you can't write 
polymorphic in-place functions very easily.

So, I guess from one perspective, Tim is arguing against things that are 
at the very core of Python itself.  I'm very resistant to his desire to 
remove or significantly alter the functional behavior.

I also think there is a very good reason to have a few methods that 
return either a view or a copy.   The reason is that there are some 
arrays that the method can't be implemented unless a copy is made.   The 
only other possibility --- "raising an error" --- is going to confuse a 
lot of new users and force them to deal with the underlying 
memory-layout of an array before they really need to.

I think the current compromise is practical and disagree strongly that 
it is somehow "evil."   It's only evil to somebody trying to do in-place 
work.  If you are doing that in a polymorphic language like Python, then 
you need to understand the actual objects you are dealing with and 
should be expected to have a more mature understanding of NumPy. 


-Travis