Martin v. Löwis wrote:
Guido van Rossum <guido@python.org> writes:
But in Mark's case (and in many other cases) there will be no problem in the future -- in Python 2.4, his C code will happily accept the positive Python longs that 0x80000000 and others will be then.
Can you please explain how this will happen? If you do
int x; PyArg_ParseTuple(args,"i",&x);
and args is (0x80000000,), what will be the value of x?
x should be 0x80000000. Whether that's a negative number in its decimal representation is really not all that important if you are interfacing to 32-bit bitmaps ;-) I honestly don't think that anyone would write x = 0x80000000 and then expect x < 0 to be True. People usually write hex representations when they are trying to do bit-level manipulations and these rarely deal with signed numeric data.
BTW, this reminds me that I've long promised a set of new format codes for PyArg_ParseTuple() to specify taking the lower N bits (for N in 8, 16, 32, 64) and throwing the rest away, without range checks.
Wouldn't Mark have to use these format codes?
-- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/