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

[Travis Oliphant]

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.
> 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 
>   
Yes, you can easily make a call to _internal.py from arrayobject.c (it's 
how some things are actually implemented). 

If you just provide a Python function to call for dtype.__str__ then 
that would suffice.
> far any difference in str() and repr() ?
> I assume that repr() has to stay exactly the way it is right now - right !?
>
>   
Yeah, the repr() probably needs to stay the same

-Travis