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 "
On Tuesday 04 November 2003 03:01 pm, Anthony Baxter wrote:
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 "
" % (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), ("
"%id(i3))) Anyone want to suggest an appropriate fix, or fix them? Otherwise I'll put it on the to-do list.
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
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).
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
Martin v. =?iso-8859-15?q?L=F6wis?= wrote 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.
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:
class a: pass ...
print a() <__main__.a instance at 0xbf6dad4c> print a() <__main__.a instance at 0xbf6dac2c> print a() <__main__.a instance at 0xbf6dad0c> print a() <__main__.a instance at 0xbf6dabcc>
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.
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).
Hm. "%x" % (id(o) & 2L*sys.maxint+1) is considerably less obvious that "%x"%id(o)
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.
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
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).
Hm. "%x" % (id(o) & 2L*sys.maxint+1)
is considerably less obvious that "%x"%id(o)
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.
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?
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/)
Guido van Rossum wrote 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.
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.
class a: pass ... b=a() repr(b) == '<__main__.a instance at 0x%x>'%id(b) __main__:1: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up True
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
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.
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