[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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
