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

[Sebastian H. <ha...@ms...>]

Travis Oliphant wrote:

>> Ticket #188   dtype should have nicer str representation
>>   Is this one now officially dead ? 
>>   "<i4"  is not intuitively readable ! '<i4' as repr() is OK 
>>    but str() should rather  return   'int32 (little endian)'
>>   
> 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 !

As far as a patch is concerned: is _internal.py already being called now 
from arrayobject.c for the str() and repr() methods ? And is there so 
far any difference in str() and repr() ?
I assume that repr() has to stay exactly the way it is right now - right !?

Thanks,
Sebastian