%x formatting of floats - behaviour change since 3.4
I'm helping out with the micropython project and am finding that one of their tests fails on CPython 3.5 (fresh build from Mercurial this morning). It comes down to this: Python 3.4.1rc1 (default, May 5 2014, 14:28:34) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information.
"%x"%16.0 '10'
Python 3.5.0a0 (default:88814d1f8c32, Jun 4 2014, 07:29:32) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or "license" for more information.
"%x"%16.0 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: %x format: an integer is required, not float
Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything about it, but my recollection doesn't mean much. ChrisA
On 6/3/2014 5:38 PM, Chris Angelico wrote:
I'm helping out with the micropython project and am finding that one of their tests fails on CPython 3.5 (fresh build from Mercurial this morning). It comes down to this:
Python 3.4.1rc1 (default, May 5 2014, 14:28:34) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information.
"%x"%16.0 '10'
Python 3.5.0a0 (default:88814d1f8c32, Jun 4 2014, 07:29:32) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or "license" for more information.
"%x"%16.0 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: %x format: an integer is required, not float
Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything about it, but my recollection doesn't mean much.
Hi, 2014-06-03 23:38 GMT+02:00 Chris Angelico <rosuav@gmail.com>:
Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything about it, but my recollection doesn't mean much.
Yes, it's intentional. See the issue for the rationale: http://bugs.python.org/issue19995 Victor
On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
2014-06-03 23:38 GMT+02:00 Chris Angelico <rosuav@gmail.com>:
Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything about it, but my recollection doesn't mean much.
Yes, it's intentional. See the issue for the rationale: http://bugs.python.org/issue19995
Thanks! I'll fix (in this case, simply remove) the test and cite that issue. ChrisA
On 6/3/2014 3:05 PM, Chris Angelico wrote:
On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
2014-06-03 23:38 GMT+02:00 Chris Angelico <rosuav@gmail.com>:
Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything about it, but my recollection doesn't mean much. Yes, it's intentional. See the issue for the rationale: http://bugs.python.org/issue19995 Thanks! I'll fix (in this case, simply remove) the test and cite that issue.
Wouldn't it be better to keep the test, but expect the operation to fail?
On Wed, Jun 4, 2014 at 8:26 AM, Glenn Linderman <v+python@g.nevcal.com> wrote:
On 6/3/2014 3:05 PM, Chris Angelico wrote:
On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
2014-06-03 23:38 GMT+02:00 Chris Angelico <rosuav@gmail.com>:
Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything about it, but my recollection doesn't mean much.
Yes, it's intentional. See the issue for the rationale: http://bugs.python.org/issue19995
Thanks! I'll fix (in this case, simply remove) the test and cite that issue.
Wouldn't it be better to keep the test, but expect the operation to fail?
The way micropython does its tests is: Run CPython on a script, then run micropython on the same script. If the output differs, it's an error. The problem is, CPython 3.3 and CPython 3.5 give different output (one gives an exception, the other works as if int(x) had been given), so it's impossible for the test to be done right. My question was mainly to ascertain whether it's the tests or my system that needed fixing. ChrisA
participants (4)
-
Chris Angelico -
Eric V. Smith -
Glenn Linderman -
Victor Stinner