[Python-Dev] int/long FutureWarning

M.-A. Lemburg mal@lemburg.com
Fri, 29 Nov 2002 11:37:04 +0100


Let me summarize this:

1. 0x80000000 and similar large hex and octal constants will
    generate a parser warning in Python 2.3 which is only useful for
    developers

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

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

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)

5. new parser markers would not be available in older Python
    versions unless they are backported

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. These should
then be backported to at least Python 2.1 and 2.2 to ensure that
extensions using these new parser markers continue to work with
older Python versions.

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

We may also extend this to m5-8 for assigning to (unsigned
LONG_LONG)s for those who need them.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/