[Thomas Wouters]
... Perhaps more people could chime in? Am I being too anal about backward compatibility here?
Yes and no ;-) Backward compatibility _is_ important, but there seems no way to know in this case whether struct's range-checking sloppiness was accidental or deliberate. Having fixed bugs in the old code several times, and been reduced to writing crap like this in the old test_struct.py: # XXX Most std integer modes fail to test for out-of-range. # The "i" and "l" codes appear to range-check OK on 32-bit boxes, but # fail to check correctly on some 64-bit ones (Tru64 Unix + Compaq C # reported by Mark Favas). BUGGY_RANGE_CHECK = "bBhHiIlL" I can't help but note several things: - If it _was_ intended that range-checking be sloppy, nobody bothered to document it. - Or even to write a comment in the code explaining that obscure intent. - When I implemented the Q (8-byte int) format code, I added correct range-checking in all cases, and nobody ever complained about that. - As noted in the comment above, we have gotten complaints about failures of struct range-checking at other integer widths. OTOH, BUGGY_RANGE_CHECK existed because I was too timid to risk making broken user code visibly broken. So, in all, I'm 95% sure 2.4's behavior is buggy, but 50% unsure that we need to warn about it before repairing it. Since you (Thomas) want warnings, and in theory it only affects the lightly-used "standard" modes, I do lean in favor of leaving the standard modes that _are_ broken (as above, not all are) broken in 2.5 but warning that this will change in 2.6.