[Python-Dev] int/long FutureWarning

Martin v. L÷wis martin@v.loewis.de
Fri, 29 Nov 2002 13:17:17 +0100


> 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