[Python-Dev] Backport new float repr to Python 2.7?
Eric Smith
eric at trueblade.com
Mon Oct 12 21:42:52 CEST 2009
More information about the Python-Dev mailing list
Mon Oct 12 21:42:52 CEST 2009
- Previous message: [Python-Dev] Backport new float repr to Python 2.7?
- Next message: [Python-Dev] Backport new float repr to Python 2.7?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Tim:] > If you don't consider Windows to be a major platform ;-) Besides that > there's just no guessing what the Microsoft double->string routines > will produce for the 17th digit, the MS routines always produce 3 > digits for the exponent in scientific notation, while AFAIK all other > platforms produce 2 digits when 3 aren't necessary. For example, on > Windows under Python 2.x: > >>>> repr(1e47) > '1e+047' >>>> repr(1e-47) > '9.9999999999999997e-048' > > and "everywhere else": > >>>> repr(1e47) > '1e+47' >>>> repr(1e-47) > '9.9999999999999997e-48' Not that it's germane to the discussion, but this 3 digit exponent on Windows was fixed in 2.6. > The leading 0 in the Window's exponents is enough to break a naive > doctest too -- and repr(x) does produce scientific notation for > "almost all" finite doubles. Why people are obsessed with the > relative handful of doubles between 1 and 1000 is beyond me ;-) > > As doctest's original author, I have no sympathy for users who burn > themselves with float output. Of course it's open to question whether > I have sympathy for anyone, ever, but that's not the issue here ;-) I agree, we shouldn't base the decision to change this based on doctests.
- Previous message: [Python-Dev] Backport new float repr to Python 2.7?
- Next message: [Python-Dev] Backport new float repr to Python 2.7?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list