Issue 5657: bad repr of itertools.count object with negative value on OS X 10.4 with 10.5 build (original) (raw)

Issue5657

Created on 2009-04-01 19:30 by ned.deily, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg85081 - (view)	Author: Ned Deily (ned.deily) *	Date: 2009-04-01 19:30
Observed failure of regression test: ====================================================================== FAIL: test_count (test.test_itertools.TestBasicOps) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te st_itertools.py", line 215, in test_count self.assertEqual(repr(c), 'count(-9)') AssertionError: 'count(4294967287)' != 'count(-9)' Problem can be reproduced using the python.org 3.0.1 OS X installer on a PPC (G3) system running 10.4: /Library/Frameworks/Python.framework/Versions/3.0$ bin/python3.0 Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from itertools import count >>> x = count(-2) >>> x count(4294967294) >>> next(x) -2 >>> x count(4294967295) >>> next(x) -1 >>> x count(0) >>> next(x) 0 >>> x count(1) >>> nad@pbg3:/Library/Frameworks/Python.framework/Versions/3.0$ uname -a Darwin pbg3.baybryj.net 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc But the same installer on another PPC (G4) system running 10.5 works fine: /Library/Frameworks/Python.framework/Versions/3.0$ bin/python3.0 Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from itertools import count >>> x = count(-2) >>> x count(-2) >>> next(x) -2 >>> nad@pbg4:/Library/Frameworks/Python.framework/Versions/3.0$ uname -a Darwin pbg4.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:39:01 PST 2008; root:xnu-1228.9.59~1/RELEASE_PPC Power Macintosh Further analysis shows that the problem is reproducible on the 10.4 system with any current build (2.x/3.x) if the installer build is made on a 10.5 system with the default deployment target of 10.3; the correct results are seen if the image is installed on a 10.5 system. If the same source snapshot is used to build an installer image on the 10.4 system, the resulting image does not exhibit this bug, either on the 10.4 or on 10.5 systems. More analysis is needed. It would be helpful if anyone with access to another 10.4 PPC or Intel system could try the above code snippet using the 3.0.1 OS X from python.org.
msg85140 - (view)	Author: Raymond Hettinger (rhettinger) *	Date: 2009-04-02 02:42
Martin, do you have any insight into this? The values being seen and the fact that it occurs only in a particular build suggests that pyport.h has inconsistent definitions for Py_ssize_t, PY_SSIZE_T_MAX, and PY_SSIZE_T_MIN. The values look like signed and unsigned values are being conflated.
msg85191 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2009-04-02 10:30
Raymond: My guess is that this is caused because the binary was build on OSX 10.5, where 'printf("%zd")' works file for negative numbers, and the tests was run on OSX 10.4, where the same printf statement doesn't work correctly. I'll experiment with a fix for this over the weekend. The fix I'm thinking of right now is to patch either configure.in or pymacconfig.h to make sure that PY_FORMAT_SIZE_T is overridden when building a binary that has a DEPLOYMENT_TARGET that is smaller than 10.5.
msg86029 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2009-04-16 13:05
I intend to fix this next weekend, therefore assigning the issue to myself.
msg86161 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2009-04-19 10:42
Fixed in r71743 (trunk), r71744 (2.6), r71746 (3.0), r71745 (3.1)