[Python-Dev] Deprecation warning on integer shifts and such
Mon, 12 Aug 2002 22:18:26 +0200
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().
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>
- If I can't dance I don't want to be part of your revolution --
Emma Goldman -