[Python-Dev] Backport new float repr to Python 2.7? (original) (raw)

Mark Dickinson dickinsm at gmail.com
Mon Oct 12 20:41:44 CEST 2009

[Guido]

I think you mean doctests? These are the primary reason I've always been hesitant to change this in 2.x.

Yes, sorry. I did of course mean doctests.

It occurs to me that any doctests that depend on the precise form of repr(x) are, in a sense, already broken, since 2.x makes no guarantees about repr(x) being consistent across platforms. It's just an accident that repr(x) in 2.x pretty much is consistent across major platforms, so long as you steer clear of IEEE 754 oddities like subnormals, nans and infinities.

[Glyph]

I'd much rather have my doctests and float-repr'ing code break on 2.7 so I can deal with it as part of a minor-version upgrade than have it break on 3.x and have to deal with this at the same time as the unicode->str explosion. It feels like a backport of this behavior would make the 2->3 transition itself a little easier.

I hadn't really thought about this aspect. I find this quite convincing.

[Guido]

PS. str(x) still seems to be using %.12g -- shouldn't it be made equal to repr() in 3.1 or 3.2? That I would call a bug, an oversight.

But str still has some value in py3k: it protects users from accumulated rounded errors produced by arithmetic operations:

Python 3.2a0 (py3k:75216:75220, Oct 3 2009, 21:38:04) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information.

0.1 + 0.2 0.30000000000000004 1.23 * 4.64 5.707199999999999 str(0.1 + 0.2) '0.3' str(1.23 * 4.64) '5.7072'

I don't know whether this makes it worth keeping str different from repr.

Mark

More information about the Python-Dev mailing list