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

[Guido van Rossum]

> The least amount of work for me would be caused by keeping "i" semantics 
> as they are, of course.

So you're using 'i', not 'l'?  Any particular reason?

> If we switch to "k" for integers in the range -2**-31..2**31-1 that 
> would not be too much work, as a lot of the code is generated (I would 
> take the quick and dirty approach of using k for all my integers). Only 
> the hand-written code would have to be massaged by hand.

Glad, that's my preferred choice too.  But note that in Python 2.4 and
beyond, 'k' will only accept positive inputs, so you'll really have to
find a way to mark your signed integer arguments up differently.

In 2.3 (and 2.2.2), I propose the following semantics for 'k': if the
argument is a Python int, a signed value within the range
[INT_MIN,INT_MAX] is required; if it is a Python long, a nonnegative
value in the range [0, 2*INT_MAX+1] is required.  These are the same
semantics that are currently used by struct.pack() for 'L', I found
out; I like these.

We'll have to niggle about the C type corresponding to 'k'.  Should it
be 'int' or 'long'?  It may not matter for you, since you expect to be
running on 32-bit hardware forever; but it matters for other potential
users of 'k'.  We could also have both 'k' and 'K', where 'k' stores
into a C int and 'K' into a C long.

I also propose to have a C API PyInt_AsUnsignedLong, which will
implement the semantics of 'K'.  Like 'i', 'k' will have to do an
explicit range test.

> If we have only pure signed and pure unsigned converters it would mean 
> an extraordinary amount of work, but luckily it seems that that is not 
> going to happen.

Not until 2.4, that is -- then 'k' (and 'K') will change to pure
unsigned.  But your hex constants and results of left shifts will
*also* be pure unsigned then; the only problem would be with Python
code that uses ~0 or -1 as a shorthand for 0xffffffff (which it ain't
on 64-bit machines today).

> It feels that way because pulling teeth is probably exactly the right 
> analogy: what you're doing is probably a good idea in the long run, but 
> right now it hurts...

OK, that's a good extension of the analogy.

Glad we're moving forward on this.

--Guido van Rossum (home page: http://www.python.org/~guido/)