[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