On May 30, 2006, at 10:47 AM, Tim Peters wrote:
[Bob Ippolito]
What should it be called instead of wrapping?
I don't know -- I don't know what it's trying to _say_ that isn't already said by saying that the input is out of bounds for the format code.
The wrapping (now overflow masking) warning happens during conversion of PyObject* to long or unsigned long. It has no idea what the destination packing format is beyond whether it's signed or unsigned. If the packing format happens to be the same size as a long, it can't possibly trigger a range warning (unless range checks are moved up the stack and all of the function signatures and code get changed to accommodate that).
When it says it's wrapping, it means that it's doing x &= (2 ^ (8 * n)) - 1 to force a number into meeting the expected range.
How is that different from what it does in this case?:
struct.pack('
That looks like "wrapping" to me too (256 & (2**(8*1)-1)== 0x00), but in this case there is no deprecation warning about wrapping. Because of that, I'm afraid you're drawing distinctions that can't make sense to users.
When it says "integer wrapping" it means that it's wrapping to fit in a long or unsigned long. n in this case is always 4 or 8 depending on the platform. The format-specific range check is separate. My description wasn't very good in the last email.
Reducing it to one warning instead of two is kinda difficult. Is it worth the trouble?
I don't understand. Every example you gave that showed a wrapping warning also showed a "format requires i <= number <= j" warning. Are there cases in which a wrapping warning is given but not a "format requires i <= number <= j" warning? If so, I simply haven't seen one (but I haven't tried all possible inputs ;-)).
Since the implementation appears (to judge from the examples) to "wrap" in every case in which any warning is given (or are there cases in which it doesn't?), I don't understand the point of distinguishing between wrapping warnings and "format requires i <= number <= j" warnings either. The latter are crystal clear.
A latter email in this thread enumerates exactly which circumstances should cause two warnings with the current implementation. -bob