> 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
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