[Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Sebastian Haase
haase at msg.ucsf.edu
Wed Sep 13 23:25:39 EDT 2006
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
More information about the NumPy-Discussion
mailing list