[Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

[Andrew Straw]

Travis Oliphant wrote:
> Sebastian Haase wrote:
>   
>> Travis Oliphant wrote:
>>
>>   
>>     
>>> It's not necessarily dead, the problem is complexity of implementation 
>>> and more clarity about how all dtypes are supposed to be printed, not 
>>> just this particular example.   A patch would be very helpful here.  If 
>>> desired it could be implemented in _internal.py and called from there in 
>>> arrayobject.c
>>>
>>> But, to get you thinking...  How should the following be printed
>>>
>>> dtype('c4')
>>>
>>> dtype('a4,i8,3f4')
>>>
>>> dtype('3f4')
>>>
>>>
>>> -Travis
>>>     
>>>       
>> I would argue that if the simple cases were addressed first those would 
>> cover 90% (if not 99% for most people) of the cases occurring in 
>> people's daily use.
>> For complex types (like 'a4,i8,3f4') I actually think the current text 
>> is compact and good.
>> (Lateron one could think about
>> 'c4' --> '4 chars'
>> '3f4' --> '3 float32s'
>>
>> but already I don't know: is there any difference between 'c4' and 
>> '4c1'?  What is the difference between 'c4' and 'a4' !?
>> )
>>
>>
>> My main focus is on the fact that you might read '<i4' as
>> "less" than 4-bytes int, which is very confusing !
>>   
>>     
> I can agree it's confusing at first, but it's the same syntax the struct 
> module uses which is the Python precedent for this.
>   
I'm happy with seeing the repr() value since I know what it means, but I
can see Sebastian's point. Perhaps there's a middle ground -- the str()
representation for simple dtypes could contain both the repr() value and
an English description. For example, something along the lines of
"dtype('<i4') (4 byte integer, little endian)". For more complex dtypes,
the repr() string could be given without any kind of English translation.

-Andrew