test warnings for "%x"%id(foo) on 2.3 branch
I'm seeing a couple of warnings that I don't remember seeing at the time of the 2.3.2 release. Given what they are, it's possible that it's just a random thing (whether the id is < 0 or not). test_minidom /home/anthony/src/py/23maint/Lib/xml/dom/minidom.py:797: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up return "<DOM Element: %s at %#x>" % (self.tagName, id(self)) test_repr /home/anthony/src/py/23maint/Lib/test/test_repr.py:91: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up eq(r(i3), ("<ClassWithFailingRepr instance at %x>"%id(i3))) Anyone want to suggest an appropriate fix, or fix them? Otherwise I'll put it on the to-do list. Anthony
On Tuesday 04 November 2003 03:01 pm, Anthony Baxter wrote:
Not sure if it's "appropriate", but what other tests appear to be doing is to explicitly mark warnings (& specifically this one) as ignored: regrtest.py:# I see no other way to suppress these warnings; regrtest.py:warnings.filterwarnings("ignore", "hex/oct constants", FutureWarning, regrtest.py: warnings.filterwarnings("ignore", "hex/oct constants", FutureWarning, test_builtin.py:warnings.filterwarnings("ignore", "hex../oct.. of negative int", test_builtin.py: FutureWarning, __name__) test_compile.py: warnings.filterwarnings("ignore", "hex/oct constants", FutureWarning) test_compile.py: warnings.filterwarnings("ignore", "hex.* of negative int", FutureWarning) test_hexoct.py:warnings.filterwarnings("ignore", "hex/oct constants", FutureWarning, Alex
Anthony Baxter <anthony@interlink.com.au> writes:
What system is this on? I find it surprising that the id is < 0: on a 32-bit machine, this should only happen if you allocate more than 2GB.
Anyone want to suggest an appropriate fix, or fix them? Otherwise I'll put it on the to-do list.
I'd reformulate them as "%x" % (id(o) & 0xffffffffL) Of course, you have to replace 0xffffffffL with (unsigned)-1 of the system (i.e. 2l*sys.maxint+1). I wonder whether creating a function sys.unsigned(id(o)) would be appropriate, which returns its arguments for positive numbers, and PyLong_FromUnsignedLong((unsigned)arg) otherwise. Regards, Martin
Redhat 10 beta3 (Fedora). I'm not entirely sure why it's generating these. Using current CVS python (although it also complains when building a 2.3.2 on this platform, but a 2.3.2 compiled on RH9 is fine. Python 2.3.2+ (#1, Nov 5 2003, 00:54:02) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
id('sdkjhfdkfhsdkjfhsdkjfhdskf') -1083363920
It seems most things have a very large id now:
I wonder if it's some sort of "randomly jumble around the address space to prevent stack-smashing" thing? I seem to recall something about Position Independant Execution in the release notes. This version of RH will be the one released in the next week or so.
Hm. "%x" % (id(o) & 2L*sys.maxint+1) is considerably less obvious that "%x"%id(o)
Possibly. I'm going to have to make the above patch to the 23 branch in any case - warnings from the standard test suite are bad. Would a different % format code be another option? Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
This warning will go away in 2.4 again, where %x with a negative int will return a hex number with a minus sign. So I'd be against introducing a new format code. I've forgotten in what code you found this, but the sys.maxint solution sounds like your best bet. In 2.4 we can also make id() return a long when the int value would be negative; I don't want to do that in 2.3 since changing the return type and value of a builtin in a minor release seems a compatibility liability -- but in 2.4 the difference between int and long will be wiped out even more than it already is, so it should be fine there. --Guido van Rossum (home page: http://www.python.org/~guido/)
The code is basically something like this: Python 2.3.2+ (#1, Nov 5 2003, 00:54:02) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
For now, I'll patch the 2.3 code in the test suite to make it not complain. If %x will return a negative hex number, then the internals of id() must make sure that they return a positive number, or whatever does the standard repr will need to change as well. I'll log a bug on SF for it. Anthony
The standard repr is written in C and uses %p, which does a platform specific thing, but typically produces an unsigned hex number of appropriate length; apparently we've not been ported to platforms where it does something else, otherwise the test would have failed there too. One can argue that the test is too constrained anyway -- why should we care about the specific hex number in the repr() of a class? I'm not for adding %p to Python's string formats; it's too implementation specific and I don't see a use for it other than matching the built-in repr(). id() has always returned negative numbers on all platforms where pointers happen to have the high bit set; apart from making this test pass in the future (which is a pretty weak argument) I don't see a problem with that, so I'm not in favor of changing it, even though it would be easy enough to change PyLong_FromVoidPtr() to call PyLong_FromLong[Long](). --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tuesday 04 November 2003 03:01 pm, Anthony Baxter wrote:
Not sure if it's "appropriate", but what other tests appear to be doing is to explicitly mark warnings (& specifically this one) as ignored: regrtest.py:# I see no other way to suppress these warnings; regrtest.py:warnings.filterwarnings("ignore", "hex/oct constants", FutureWarning, regrtest.py: warnings.filterwarnings("ignore", "hex/oct constants", FutureWarning, test_builtin.py:warnings.filterwarnings("ignore", "hex../oct.. of negative int", test_builtin.py: FutureWarning, __name__) test_compile.py: warnings.filterwarnings("ignore", "hex/oct constants", FutureWarning) test_compile.py: warnings.filterwarnings("ignore", "hex.* of negative int", FutureWarning) test_hexoct.py:warnings.filterwarnings("ignore", "hex/oct constants", FutureWarning, Alex
Anthony Baxter <anthony@interlink.com.au> writes:
What system is this on? I find it surprising that the id is < 0: on a 32-bit machine, this should only happen if you allocate more than 2GB.
Anyone want to suggest an appropriate fix, or fix them? Otherwise I'll put it on the to-do list.
I'd reformulate them as "%x" % (id(o) & 0xffffffffL) Of course, you have to replace 0xffffffffL with (unsigned)-1 of the system (i.e. 2l*sys.maxint+1). I wonder whether creating a function sys.unsigned(id(o)) would be appropriate, which returns its arguments for positive numbers, and PyLong_FromUnsignedLong((unsigned)arg) otherwise. Regards, Martin
Redhat 10 beta3 (Fedora). I'm not entirely sure why it's generating these. Using current CVS python (although it also complains when building a 2.3.2 on this platform, but a 2.3.2 compiled on RH9 is fine. Python 2.3.2+ (#1, Nov 5 2003, 00:54:02) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
id('sdkjhfdkfhsdkjfhsdkjfhdskf') -1083363920
It seems most things have a very large id now:
I wonder if it's some sort of "randomly jumble around the address space to prevent stack-smashing" thing? I seem to recall something about Position Independant Execution in the release notes. This version of RH will be the one released in the next week or so.
Hm. "%x" % (id(o) & 2L*sys.maxint+1) is considerably less obvious that "%x"%id(o)
Possibly. I'm going to have to make the above patch to the 23 branch in any case - warnings from the standard test suite are bad. Would a different % format code be another option? Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
This warning will go away in 2.4 again, where %x with a negative int will return a hex number with a minus sign. So I'd be against introducing a new format code. I've forgotten in what code you found this, but the sys.maxint solution sounds like your best bet. In 2.4 we can also make id() return a long when the int value would be negative; I don't want to do that in 2.3 since changing the return type and value of a builtin in a minor release seems a compatibility liability -- but in 2.4 the difference between int and long will be wiped out even more than it already is, so it should be fine there. --Guido van Rossum (home page: http://www.python.org/~guido/)
The code is basically something like this: Python 2.3.2+ (#1, Nov 5 2003, 00:54:02) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
For now, I'll patch the 2.3 code in the test suite to make it not complain. If %x will return a negative hex number, then the internals of id() must make sure that they return a positive number, or whatever does the standard repr will need to change as well. I'll log a bug on SF for it. Anthony
The standard repr is written in C and uses %p, which does a platform specific thing, but typically produces an unsigned hex number of appropriate length; apparently we've not been ported to platforms where it does something else, otherwise the test would have failed there too. One can argue that the test is too constrained anyway -- why should we care about the specific hex number in the repr() of a class? I'm not for adding %p to Python's string formats; it's too implementation specific and I don't see a use for it other than matching the built-in repr(). id() has always returned negative numbers on all platforms where pointers happen to have the high bit set; apart from making this test pass in the future (which is a pretty weak argument) I don't see a problem with that, so I'm not in favor of changing it, even though it would be easy enough to change PyLong_FromVoidPtr() to call PyLong_FromLong[Long](). --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
Alex Martelli -
Anthony Baxter -
Guido van Rossum -
martin＠v.loewis.de