[Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

Guido van Rossum guido at python.org
Fri Jun 27 21:04:34 CEST 2008


PS. I can't get excited about having support for this in %-style
format strings (and even less so now %a already means "call ascii()").
It would be easy enough to add support for it to float.__format__()
though.

On Fri, Jun 27, 2008 at 12:02 PM, Guido van Rossum <guido at python.org> wrote:
> Now that I've learned about the hex float format supported by C++ and
> Java, I wonder if it wouldn't be better to support conversion to and
> from that format and nothing else.
>
> E.g.
>
>>>> math.tohex(3.14)
> '0x1.91eb851eb851fp+1'
>>>> math.fromhex('0x1.91eb851eb851fp+1')
> 3.1400000000000001
>>>>
>
> BTW I am still hoping to be able the output of the second command to
> just "3.14" but the tracker issue for that
> (http://bugs.python.org/issue1580) is stuck on trying to decide
> whether it's okay to have repr(<float>) occasionally return a string
> that doesn't convert to the exact same value on another platform. (My
> preferred approach would ensure that it does convert to the same value
> on the same platform, because that's how I'd compute it.) Perhaps the
> existance of an unambiguous hex format that is also interchangeable
> with Java and C (and presumably C++) would alleviate that concern.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list