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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4