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

[Jack Jansen]

On Tuesday, August 13, 2002, at 12:20 , Guido van Rossum wrote:

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

No, sorry. It's l everywhere.

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

Huh??! Now you've confused me. If "k" means "32 bit mask", why would it 
be changed in 2.4 not to accept negative values? "-1" is a perfectly 
normal way to specify "0xffffffff" in C usage...

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

I don't see the point, really. Why not allow [INT_MIN, 2*INT_MAX+1]? If 
the "k" specifier is especially meant for bit patterns why not have 
semantics of "anything goes, unless we are absolutely sure it isn't 
going to fit"?

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

How about k1 for a byte, k2 for a short, k4 for a long and k8 for a long 
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.

In my proposal these would then probably become PyInt_As1Byte, 
PyInt_As2Bytes, PyInt_As4Bytes and PyInt_As8Bytes.
--
- 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 -