Martin v. L=F6wis wrote: > Guido van Rossum <guido@python.org> writes: >=20 >=20 >>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. >=20 >=20 > Can you please explain how this will happen? If you do=20 >=20 > int x; > PyArg_ParseTuple(args,"i",&x); >=20 > 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 =3D 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.=20 >=20 > Wouldn't Mark have to use these format codes? --=20 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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4