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

[Jack Jansen]

On maandag, augustus 12, 2002, at 05:37 , Guido van Rossum wrote:
> 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).  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().

Ow, pleeeeeeeeeeeeeeeeeeeeeeeeaaaaaase........

Just before 2.1 was released (or was it 2.0?) on a whim someone 
"fixed" the short integer handling to bother about signs, in a 
backward-incompatible way, despite that fact that about 95% of 
the short PyArg_Parse formats in the core were mine, and I asked 
for some form of backward compatibility. I spent about 2 weeks 
going over a few thousand API calls to fix this mess at a time I 
had more than enough other work on my hands.

Can we please make this change in a backwards-compatible way, 
i.e. leave the i and l formats alone and use something new for 
"range-checked-int" and "range-checked-long"?

I already fear that I have to come up with some sort of a fix 
for the range-check warning (more than 6000 lines worth of 
constant definitions that can currently be copied verbatim from 
C header files to Python will have to be parsed, and computed, 
and all these things can contain references to other constants, 
strings and who knows what more, see Mac/Lib/Carbon/*.py), I 
really could do without more work on my plate...
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -