array.array() setter incorrectly handle overflows for 'e' type code #156864
Description
Bug report
Bug description:
Consider this:
>>> import array
>>> a = array.array('e', [123])
>>> a[0] = 123456 # doesn't fit in _Float16 but fits in _Float32
Traceback (most recent call last):
File "<python-input-5>", line 1, in <module>
a[0] = 123456
~^^^
OverflowError: float too large to pack with e format
>>> a
array('e', [123.0])
>>> a[0] = 1e300 # doesn't fit neither in _Float32 nor in _Float16
>>> a
array('e', [inf])That's happened because we use PyArg_Parse() function with 'f' format code to parse floats. Then in the second case PyFloat_Pack2() seen plain infinity and doesn't trigger overflow.
I believe both examples should trigger overflows.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Activity
[-]array.array() setters incorrectly handle overflows for 'e' type code[/-][+]array.array() setter incorrectly handle overflows for 'e' type code[/+]vstinner commentedon Sep 3, 2026
f_setitem()andcf_setitem()have the same behavior:Should we change
fandZfbehavior as well to be consistent?vstinner commentedon Sep 3, 2026
This issue looks similar to issue gh-156867. I would prefer to merge the two issues and fix all issues at once.
skirpichev commentedon Sep 3, 2026
This one and #156867 looks less controversial for me. Both already have pr's ready.
Slightly different. Those don't raise exceptions at all (only for bigints). See #156865. Similar inconsistencies are present in the memoryview and ctypes.
I can merge this one, #156867 and #156865. But in principle - all issues cover different cases...