[Python-Dev] hex constants, bit patterns, PEP 237 warnings and gettext

Barry A. Warsaw barry@zope.com
Wed, 14 Aug 2002 01:06:35 -0400


Ok, I admit that I've only tangentially followed the thread on PEP 237
deprecation warnings, and I've just skimmed PEP 237 but I'm pretty
tired, so I must be missing something.

The deprecation warnings on compiling Lib/gettext.py are complaining
about these three hex constants:

    ...
    # Magic number of .mo files
    LE_MAGIC = 0x950412de
    BE_MAGIC = 0xde120495

    def _parse(self, fp):
        """Override this method to support alternative .mo formats."""
        # We need to & all 32 bit unsigned integers with 0xffffffff for
        # portability to 64 bit machines.
        MASK = 0xffffffff

These really are intended as 32 bit patterns, not signed integers.
Hex constants seem like the most straightforward way to spell such bit
patterns.  If I wanted MASK to be -1 I would have spelled it that way!

What gettext wants to do is to read the first 4 bytes from a file, &
it with the MASK to get a 32 bit pattern and then compare that against
two known patterns to see if we're looking at big-ending or
little-ending.  This is as recommended in the GNU gettext docs.

Now, if I add a trailing `L' to each of those constants the warnings
go away, which seems odd to me given that PEP 237 is trying to do away
with the int/long distinction and will eventually make the trailing
`L' illegal!

So I clearly don't understand why I need to add the trailing-L to
quiet the warnings, and PEP 237 doesn't quiet help me understand why
hex and oct constants > sys.maxint have to have warnings (I understand
why shifts and such need warnings).  Maybe it's just me, but if I want
a bit pattern, I write a hex constant; I'm never going to write -1 as
0xffffffff.

So if "0x950412de" isn't the right way to write a 32 bit pattern, what
is? "0x950412deL"?  If so, what happens when the trailing-L becomes
illegal?  Seems like I'll be caught in a trap -- help me out! :)

-Barry