[Python-Dev] int/long FutureWarning
Fri, 29 Nov 2002 11:15:20 +1100
> > Guido van Rossum <email@example.com> 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.