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

[Paul Svensson]

On Tue, 13 Aug 2002, Guido van Rossum wrote:

>> >> 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...
>
>Hm, in Python I'd hope that people would write 0xffffffff if they want
>32 one bits -- -1L has an infinite number of one bits, and on 64-bit
>systems, -1 has 64 one-bits instead of 32.  Most masks are formed by
>taking a small positive constant (e.g. 1 or 0xff) and shifting it
>left.  In Python 2.4 that will always return a positive value.
>
>But if you really don't like this, we could do something different --
>'k' could simply give you the lower 32 bits of the value.  (Or the
>lower sizeof(long)*8 bits???).

For a mask, it makes some kind of sense to require all the high bits,
those not ports of the mask, to be all the same; it makes it less likely
that something important gets lost when they're trimmed off.
But, don't all ones make just as much sense as all zeros ?

Even with unified numbers, -1 (or ~0) seems to be a reasonable
way to spell a bitmask with all bits set, without having to know
how many "all" are.

	/Paul