[SciPy-dev] array dtypechar wrong or not

Pearu Peterson pearu at scipy.org
Tue Oct 25 13:24:47 CDT 2005



On Tue, 25 Oct 2005, Travis Oliphant wrote:

> Pearu Peterson wrote:
>
>> Hi,
>>
>> Note that
>>
>> In [142]: array(array([1,2],dtype='I'),dtype='L').dtypechar
>> Out[142]: 'I'
>>
>> In [143]: array(array([1,2],dtype='L'),dtype='I').dtypechar
>> Out[143]: 'L'
>>
>> I have expected 'L' and 'I', respectively. It this a bug?
>>
>>
>>
> It's not really a bug,  Basically, on your platform 'I' and 'L' are
> equivalent types, and so conversion is not done.   I suppose that the
> typenumber could change, though,  instead of doing nothing.
>
> Basically, it's the code in array_fromarray.  Because 'I' and 'L' are
> equivalent types on your platform, only an INCREF is done.   If we
> change the typecode as well as INCREF, then the original array would be
> changed, which might be surprising as well:
>
> a = array([1,2],dtype='I')
>
> b = array(a,dtype='L')
>
> b will point to a.  If we change b to have typecode 'L', then a will
> also change.  This would be surprising, I think.

I agree with you up to a point that by default array should make a copy.
Changing `b` should not change `a`, so why should `a` change on changing 
`b` typecode anyway? As it is now, array does not perform a complete 
copy, that is, it ignores dtype argument.

In practical application this issue doesn't matter much probably. I 
noticed this behaviour and was forced to add some extra hooks to deal 
with this behavior for f2py unittests that I am implementing now.

I am not requesting to change the current behavior. I am just pointing out 
an unexpected behaviour. If there is no obvious way to change 
this, then nevermind, but if there is, then that would be good.

Pearu




More information about the Scipy-dev mailing list