[Python-Dev] Deprecation warning on integer shifts and such

[M.-A. Lemburg]

Guido van Rossum wrote:
>>Guido van Rossum <guido@python.org> writes:
>>
>>
>>>There's no excuse for that any more.  The 'i' and 'l' format chars of
>>>PyArg_Parse* and PyInt_AsLong() both work for longs as well as for
>>>ints.

Sigh.

> Martin:
> 
>>There is a change, of course: Passing 0xff<<24 to a function that uses
>>the "i" converter will produce an OverflowError, whereas it previously
>>would pass in the negative numbers.
> 
> 
> And unfortunately the same will happen for the "l" converter
> (PyInt_AsLong(<long>) does a signed range check.
> 
> 
>>For cases of "I want 32 bits in an int", you'll have to accept both
>>signed and unsigned 32 bits - something that is currently not
>>supported in ParseTuple.
> 
> 
> Oops.  Darn.  You're right.  Sigh.  That's painful.  We have to add a
> new format code (or more) to accept signed 32-bit ints but also longs
> in range(32). 

Rather than inventing something new to be compatible to the existing
old status quo, I'd rather like to see new format codes for unsigned
integers and/or longs and have the existing ones support the new
status quo.

 > This should be added in 2.3 so extensions can start
> using it now, and user code can start passing longs in range(2**32)
> now.  I propose 'k' (for masK).  We should backport this to 2.2.2 as
> well.  Plus a variant on PyInt_AsLong() with the same semantics, maybe
> named PyInt_AsMask().
> 
> Any takers?

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