I must be missing something, but I can't understand why the existing PyArg_ParseTuple codes can't take on a kind of "hybrid" approach for b/w compatibility. This could mean, assuming a 32 bit platform, that 'l':
c_func_taking_int( 0x80000000L ) -> 0x8000000 c_func_taking_int( 0xFFFFFFFFL ) -> 0xFFFFFFFF c_func_taking_int( 0x100000000L ) -> OverflowError c_func_taking_int( -0x80000001L ) -> whatever we like <wink>
We might as well not bother with range checking then, which would be backwards incompatible. :-(
The new format codes can be more precise in their handling of these objects and their sign.
I can't see a real downside to this. There is no way someone can get (+-)0x80000001L into a C int via ParseTuple("l") now, so we are not breaking anything. When the arg is an int object or a long in the currently supported range, the semantics are identical. A few cases may exist where an OverflowError would have been thrown but no longer is, but that behaviour is unlikely to be relied upon.
The only case I see this failing with is bitwise rotates. Today: c_func_taking_int( 0x80000000<<1 ) -> 0x0
but with my semantics above, it would yield
c_func_taking_int( 0x80000000L<<1 ) -> OverflowError
You get a slightly different warning for left shifts that actually lose bits, and I don't think that warning is causing you any pain.
re-defining 'l' to mean "lower 'n' bits" would solve this, but I accept this is going too far. Certainly for all my "constant files", all bitwise rotate operations are "safe" in terms of losing bits - just not in changing sign - so I believe this would still work for me.
I am sure I am missing something, but I can't see it. I am ready to feel foolish <wink>. It would certainly be easier for me to work on such a strategy than to convert all my extensions.
I don't have enough time to think about this right now (and I'm dying to go to bed), but I agree that something needs to be done. Originally the PEP didn't prescribe warnings for this. Maybe we can just disable the warnings by default? Or maybe we can use the "__future__" suggestion, since it's the only way to signal to the parser not to issue the warnings. (One problem with the warning about hex constants is that because the entire module is parsed before it is executed, putting a warnings.filterwarnings() call in the module itself is ineffective; you must put it somewhere else. This is not a problem with the warnings about <<. A __future__ statement is a signal to the parser.) --Guido van Rossum (home page: http://www.python.org/~guido/)