1. 0x80000000 and similar large hex and octal constants will generate a parser warning in Python 2.3 which is only useful for developers
Correct. The same holds for any other warning, and for all uncaught exceptions: the message you get is only useful for the author of the software.
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
Correct.
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 ?)
Correct, although you probably meant to omit the L in both cases. I think the intention is that int(x) is x if x is long.
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)
I'm not sure about the proportions, i.e. whether the "ints are bitmaps" case is more or less often than the "ints are ints" case.
5. new parser markers would not be available in older Python versions unless they are backported
Correct.
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.
The same is true for any other warning. The problem with not printing warnings by default is that it removes much of the application for the warning: To forcefully indicate that something will change. If we would only want to tell those who want to hear, we could just write it all in the documentation - if you read the documentation, you will know, if you don't, you won't. This approach was heavily critized in the past, and lead to the introduction of warnings.
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).
I'm not sure this would work for all cases. If you have things like fcntl operation codes which you generate from header files, the format argument depends on sizeof(long), so writing a portable fcntl module would be difficult with these format markers. Regards, Martin