Let me summarize this: 1. 0x80000000 and similar large hex and octal constants will generate a parser warning in Python 2.3 which is only useful for developers 2. x = 0x80000000 gives a signed integer in Python <=2.2 and long(x) results in -2147483648L; int(0x80000000L) gives an OverflowError in Python <=2.2 3. x = 0x80000000L gives a long integer 2147483648L in Python >=2.4; int(0x80000000L) returns a long in Python >=2.4 or generates an OverflowError (no idea ?) 4. C extensions have typically used "i" to get at integer values and often don't care for the sign (that is, they use them as if they were unsigned ints) 5. new parser markers would not be available in older Python versions unless they are backported To me the picture looks as if the warnings should only be printed on request by a developer (not per default) and that new parser markers are the only way to get everyone satisfied. These should then be backported to at least Python 2.1 and 2.2 to ensure that extensions using these new parser markers continue to work with older Python versions. Since the new parser markers will need to mask bitmaps, I suggest to use "m#" as new marker with # being 1,2,3 or 4 representing the number of bytes to mask, i.e. "m1" gives ((unsigned long)value & 0xF), "m2" gives ((unsigned long)value & 0xFF), etc. The marker variable will have to reference an (unsigned int). We may also extend this to m5-8 for assigning to (unsigned LONG_LONG)s for those who need them. -- 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/