[Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
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). Apart from simplifying the internals a little bit, one nice feature of this change is that it removes the differences in formatting between printing a float and printing a container of floats: l = [1/3, 1/5, 1/7] print(l) [0., 0.2, 0.14285714285714285] print(l[0], l[1], l[2]) 0. 0.2 0.142857142857 Any thoughts or comments on this? There's a working patch at http://bugs.python.org/issue9337 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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
On 29/07/2010 19:47, 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). Apart from simplifying the internals a little bit, one nice feature of this change is that it removes the differences in formatting between printing a float and printing a container of floats: l = [1/3, 1/5, 1/7] print(l) [0., 0.2, 0.14285714285714285] print(l[0], l[1], l[2]) 0. 0.2 0.142857142857 Any thoughts or comments on this? There's a working patch at http://bugs.python.org/issue9337 +1 Michael 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
Wiadomość napisana przez Mark Dickinson w dniu 2010-07-29, o godz. 20:47: 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). Any thoughts or comments on this? +1 -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ 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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
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. 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? IIRC, some other tools like matlab have a relatively compact default display size for floats, perhaps because formatting matrices becomes awkward when there are too many digits shown and because many of those digits are insignificant. Also, I think those tools have a way to globally change the default number of digits. Am curious about your thoughts on the problem we're trying to solve and the implications of changing the default. Raymond ___ 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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
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. 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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
On 7/29/2010 4:30 PM, Mark Dickinson wrote: 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. With this change, I believe the only difference between str(ob) and repr(ob) will be the addition of quotes. If so, perhaps this could be noted in the repr entry. Terry Jan Reedy ___ 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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
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. +1 for making the change to 3.2 +0 for 2.7 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. Thanks for listing the advantages. Sounds like it is worth the cost. It also really calls into question whether there are good reasons for other types to have a __str__ that is different than their __repr__. Raymond ___ 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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
2010/7/29 Raymond Hettinger raymond.hettin...@gmail.com: 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. +1 for making the change to 3.2 +0 for 2.7 -1 for 2.7. -- Regards, Benjamin ___ 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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
On Thu, Jul 29, 2010 at 3:30 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: It also really calls into question whether there are good reasons for other types to have a __str__ that is different than their __repr__. Maybe, but there is tons of 3rd party code that uses this distinction. -- --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
Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2
On Thu, Jul 29, 2010 at 6:30 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: .. It also really calls into question whether there are good reasons for other types to have a __str__ that is different than their __repr__. For strings, the distinction is very useful. In this and many other cases unifying str and repr would mean making a choice between readability and parseability. ___ 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
