[Martin]
Guido van Rossum <guido@python.org> writes:
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. ... Wouldn't Mark have to use these format codes?
That's what I meant.
Well, I am afraid it is slightly more than "no problem" for me if it means I need to read the doc for and potentially touch *every single* function in the Win32 extensions that accepts an integer as an input arg. 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> 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 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. Mark.