Hi all,
The Python binding in libxml2 uses the following code for __repr__():
class xmlNode(xmlCore):
def __init__(self, _obj=None):
self._o = None
xmlCore.__init__(self, _obj=_obj) def __repr__(self):
return "<xmlNode (%s) object at 0x%x>" % (self.name, id (self))With Python 2.3.4 I'm seeing warnings like the one below:
<frozen module libxml2>:2357: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up
I believe this is caused by the memory address having the sign bit set, causing builtin_id() to return a negative integer.
I grepped around in the Python standard library and found a rather awkward work-around that seems to be slowly propagating to various module using the "'%x' % id(self)" idiom:
Lib/asyncore.py:
# On some systems (RH10) id() can be a negative number.
# work around this.
MAX = 2L*sys.maxint+1
return '<%s at %#x>' % (' '.join(status), id(self)&MAX)$ grep -r 'can be a negative number' *
Lib/asyncore.py: # On some systems (RH10) id() can be a negative number.
Lib/repr.py: # On some systems (RH10) id() can be a negative number.
Lib/tarfile.py: # On some systems (RH10) id() can be a negative number.
Lib/test/test_repr.py: # On some systems (RH10) id() can be a negative number.
Lib/xml/dom/minidom.py: # On some systems (RH10) id() can be a negative number.
There are many modules that do not have this work-around in Python 2.3.4.
Wouldn't it be more elegant to make builtin_id() return an unsigned long integer? Is the performance impact too great?
A long integer is used on platforms where SIZEOF_VOID_P > SIZEOF_LONG (most 64 bit platforms?), so all Python code must be prepared to handle it already...
Troels _______________________________________________ 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
