[Python-Dev] Backport new float repr to Python 2.7?

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