I'm adding "long long" integral types to struct (in native mode, "long long"
or __int64 on platforms that have them; in standard mode, 64 bits).
This is proving harder than it should be, because the code that's already
there is schizophrenic across boundaries, so is failing as a base to build
on (raises more questions than it answers). Like:
>>> x = 256
>>> struct.pack("b", x) # complains about magnitude in native mode
Traceback (most recent call last):
File "<stdin>", line 1, in ?
struct.error: byte format requires -128<=number<=127
>>> struct.pack("=b", x) # but doesn't with native order + std align
'\x00'
>>> struct.pack("<b", x) # or when little-endian (ditto big-endian)
'\x00'
>>> struct.pack("<b", 256L) # too-long *longs* also OK in little-endian
'\x00'
>>> struct.pack("<b", 256256256256L) # but not if they're "too too-long"
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: long int too large to convert
>>>
Much the same is true of other small int sizes: you can't predict what will
happen without trying it; and once you get to ints, no range-checking is
performed even in native mode.
Surely this can't stand, but what do people *want*? My preference is to
raise the same "byte format requires -128<=number<=127" exception in all
these cases; OTOH, the code structure fights that, working with Python longs
is clumsy in C, and there are other "undocumented features" here that may or
may not be accidents:
>>> struct.pack("B", 234.3)
'\xea'
>>>
That is, did we *intend* to accept floats packed via integer typecodes?
Feature or bug?
In the other (unpack) direction, the docs say for 'I' (unsigned int):
The "I" conversion code will convert to a Python long if the
C int is the same size as a C long, which is typical on most
modern systems. If a C int is smaller than a C long, an Python
integer will be created instead.
That's in a footnote. In another part, they say:
For the "I" and "L" format characters, the return value is a
Python long integer.
The footnote is wrong -- but is the footnote what was intended (somebody
went to a fair bit of work to write all the stuff <wink>)?
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