On Thu, Jul 29, 2010 at 1:30 PM, Mark Dickinson <dicki...@gmail.com> wrote: > On Thu, Jul 29, 2010 at 8:16 PM, Raymond Hettinger > <raymond.hettin...@gmail.com> wrote: >> >> On Jul 29, 2010, at 11:47 AM, Mark Dickinson wrote: >> >>> Now that we've got the short float repr in Python, there's less value >>> in having float.__str__ truncate to 12 significant digits (as it >>> currently does). For Python 3.2, I propose making float.__str__ use >>> the same algorithm as float.__repr__ for its output (and similarly for >>> complex). >> >> When you proposed the idea at EuroPython, it seemed reasonable >> but we didn't go into the pros and cons. The downsides include >> breaking tests, changing the output of report generating scripts >> that aren't using string formatting, and it introduces another >> inter-version incompatibility. > > Yes, I agree that the change has potential for breakage; it's a > change that probably would have been unacceptable for Python 2.7; for > Python 3.2 I think there's a little more scope, since 3.x has fewer > users. And those users it does have at the moment are the early > adopters, who with any luck may be more tolerant of this level of > breakage. (By the time we get to 3.2 -> 3.3 that's probably not going > to be true any more.) Really, this change should have gone into 3.1. > > FWIW, the change broke very few of the standard library tests (as Eric > Smith verified): there was a (somewhat buggy) doctest in > test_tokenize that needed fixing, and test_unicodedata computes a > checksum that depends on the str() of various numeric values. Apart > from those, only test_float and test_complex needed fixing to reflect > the __str__ method changes. > >> The only obvious advantage is >> that it makes float.__repr__ and float.__str__ the same, making >> one less thing to explain. Can you elaborate on other advantages? >> Is there something wrong with the current way? > > That's one advantage; as mentioned earlier the difference between str > and repr causes confusion for floats in containers, where users don't > realize that two different operations are being used. This is a > genuine problem: I've answered questions about this a couple of times > on the #python IRC channel. > > Another advantage is that is makes 'str' faithful: that is, if x and > y are distinct floats then str(x) and str(y) are guaranteed distinct. > I know I should know better, but I've been bitten by the lack of > faithfulness a couple of times when debugging floating-point problems: > I insert a "print(x, y)" line into the code for debugging purposes > and still wonder why my 'assertEqual(x, y)' test is failing even > though x and y look the same; only then do I remember that I need to > use repr instead. > > As you say, it's just one less surprise, and one less thing to > explain: a small shrinkage of the mental footprint of the language.
+1 from me for all the reasons Mark mentioned. -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
