[Numpy-discussion] formatting issues, locale and co

David Cournapeau david@ar.media.kyoto-u.ac...
Mon Dec 29 22:46:30 CST 2008

Charles R Harris wrote:
>     Yes, I meant that I did not understand the code path in that case. I
>     realize that I don't know how to get the (C) call graph between two
>     code points in python, that would be useful. Where are you dtrace on
>     linux when I need you :)
> I'm not sure we are quite on the same page here.

Yep, indeed. I think my bogus example did not help :) The right test
script use float('inf'), not complex('inf').

> The float32 object has a "convert to python float" method, (which I
> don't recall at the moment and I don't have the source to hand). So
> when %f appears in the format string that method is called and the
> resulting python float is formatted in the python way.

I think that's not the case for '%f', because the 'python' way is to
print 'inf', not '1.#INF' (at least on 2.6 - on 2.5, it is always
'1.#INF' on windows). If you use a pure C program on windows, you will
get '1.#INF', etc... instead of 'inf'. repr, str, print all call the C
format_float function, which takes care of fomatting 'inf' and co the
'python' way.

So getting '1.#INF'  from python suggests me that python does not format
it in the '%f' case - and I don't know the code path at that point. For
'%s', it goes through tp_str, for print a, it goes through tp_print, but
for '%f' ?

>     a = complex('inf')
>     print a # -> print inf
>     print '%s' % a # -> print inf
>     print '%f' % a # -> print 1.#INF
> How does a python inf display on windows?

As stated: it depends. 'inf' or '1.#INF', the later being the same as
the formatting done within the MS runtime.

>     Which suggests that in that case, it gets directly to stdio without
>     much formatting work from python. Maybe it is an oversight ? Anyway, I
>     think it would be useful to override the tp_print member ( to avoid
>     'print a' printing 1.#INF).
> Sounds like the sort of thing the python folks would want to clean up,
> just as you have for numpy.

The thing is since I don't understand what happens in the print '%f'
case, I don't know how to clean it up, if it is at all possible. But in
anyway, it means that with my changes, we are not worse than python
itself, and I think we are better than before,



More information about the Numpy-discussion mailing list