[Python-Dev] int/long FutureWarning

[Guido van Rossum]

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