Hello,
> val = struct.unpack("I", struct.pack("i", id(self)))
This may not always work. The struct module (according to
http://docs.python.org/library/struct.html) can be used to
"[perform] conversions between Python values and C structs
represented as Python strings". The struct.pack("i", id(self)) call
converts the result from id(self) to a C struct. The "i" means that
the C struct will contain a C 'int'. The unpack call will convert
the C 'int' variable back into a Python value by interpreting the
C 'int' as an 'unsigned int'. This is why the result of printing is
a non-negative value when packing/unpacking.
According to the Python documentation at
http://docs.python.org/library/functions.html, the id(...)
function may return an integer or long integer. Packing
a long integer with "i" is problematic:
>>> import sys
>>> import struct
>>> struct.pack('i', sys.maxint)
'\xff\xff\xff\x7f'
>>> struct.pack('i', sys.maxint+1)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to int
This may not be the only issue. According to the documentation of
struct: "By default, C numbers are represented in the machine’s
native format and byte order, and properly aligned by skipping
pad bytes if necessary (according to the rules used by the C
compiler)." Therefore it may not give consistent results on different
machines? You could supply specific byte order, size and alignment
options (standard instead of native), thereby solving that
problem?
I'm not sure about all the details of the above. Some of it may
be incorrect. However, if you decide to use it, you better first
make sure it ALWAYS works.
Dennis
A.T.Hofkamp wrote:
> David Beazley wrote:
>
>> I can't replicate any of the warning messages you report--even with
>> Python 2.3
>> Are you running Python in some special mode or with special command
>> line options?
>
>
> The problem appears when the highest bit of the int is set (bit 31 of
> a 32 bit number).
>
> In Python 2.4 (and higher, apparently), such a value is considered to
> be negative, while older Pythons consider such values to be unsigned
> with %u, %o, %x, and %X string formatting.
>
> Problem and fix in the program below (although I do not understand how
> the fix works):
>
> ================================================
> # prn_id.py
> import struct
>
> class A(object):
> def p(self): # Demonstrates the problem
> print "p:id(self)=0x%x" % id(self)
>
> def q(self): # Casting does not work (other than removing the
> warning)
> print "q:id(self)=0x%x" % long(id(self))
>
> def y(self): # This fixes the problem
> val = struct.unpack("I", struct.pack("i", id(self)))
> print "y:id(self)=0x%x" % val
>
> a = A()
> print "---------"
> print "P:"
> a.p()
> print "---------"
> print "Q:"
> a.q()
> print "---------"
> print "Y:"
> a.y()
> print "---------"
> ================================================
>
> $ python2.3 prn_id.py
> ---------
> P:
> prn_id.py:5: FutureWarning: %u/%o/%x/%X of negative int will return a
> signed string in Python 2.4 and up
> print "p:id(self)=0x%x" % id(self)
> p:id(self)=0xb7ef8fac
> ---------
> Q:
> q:id(self)=0x-48107054
> ---------
> Y:
> y:id(self)=0xb7ef8fac
> ---------
>
> Notice the negative value printed by a.q()
>
> ================================================
>
> $ python2.4 prn_id.py
> ---------
> P:
> p:id(self)=0x-480fc9f4
> ---------
> Q:
> q:id(self)=0x-480fc9f4
> ---------
> Y:
> y:id(self)=0xb7f0360c
> ---------
>
> Python 2.4 prints a negative value more often (as promised by the
> FutureWarning).
>
> ================================================
>
> Sincerely,
> Albert
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"ply-hack" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/ply-hack?hl=en
-~----------~----~----~----~------~----~------~--~---