You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Return the string representing a character whose Unicode code
point is the integer i. [...] The valid range for the argument
is from 0 through 1,114,111 (0x10FFFF in base 16). ValueError
will be raised if i is outside that range.
If however a value > 0x7fffffff (or < -0x80000000) is provided, the function raises an Overflow error:
$ python3 -c 'print(chr(0x80000000))'
Traceback (most recent call last):
File "<string>", line 1, in<module>OverflowError: signed integer is greater than maximum
This is either a documentation problem or (more like) an implementation issue. I attached a patch that fixes the issue for me. (I'm not sure however if I should call PyErr_Clear() before raising ValueError.)
Perhaps this issue should be raised on Python-Dev, since it changes the old and well-known behavior of buildins. I think that ValueError is more appropriate, but in past we decided to keep OverflowError for compatibility.
If change chr(), other code needs to be changed. "%c", PyUnicode_FromOrdinal(), PyUnicode_Format(), and possible the same for bytes.
>>> print(chr(0x80000000))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C int
Given that this is a long standing behaviour and there's little reason to be passing large values here, should we just document that chr can raise OverflowError?
Also note "%c" % 1114113 raises OverflowError, should that raise ValueError instead?
Activity
ukl commentedon Jan 17, 2018
Hello,
the description for chr (from https://docs.python.org/3/library/functions.html#chr) reads as:
If however a value > 0x7fffffff (or < -0x80000000) is provided, the function raises an Overflow error:
This is either a documentation problem or (more like) an implementation issue. I attached a patch that fixes the issue for me. (I'm not sure however if I should call PyErr_Clear() before raising ValueError.)
vstinner commentedon Jan 17, 2018
It's more an implementation issue.
I proposed PR 5218 to also raise a ValueError on overflow.
I propose to only change Python 3.7, and only Python 2.7 and 3.6 unchanged.
terryjreedy commentedon Jan 19, 2018
The message I get on Windows is
OverflowError: Python int too large to convert to C long
Given that the exception type is documented, making this a clear bug, I would be tempted to fix in 3.6 also. But your decision.
serhiy-storchaka commentedon Jan 20, 2018
Perhaps this issue should be raised on Python-Dev, since it changes the old and well-known behavior of buildins. I think that ValueError is more appropriate, but in past we decided to keep OverflowError for compatibility.
If change chr(), other code needs to be changed. "%c", PyUnicode_FromOrdinal(), PyUnicode_Format(), and possible the same for bytes.
See also bpo-29833 and bpo-15988.
iritkatriel commentedon Nov 21, 2021
Still raising OVerflowError on 3.11:
Merge branch 'main' into pythongh-76763
py-w3lib: updated to 2.1.2
pythongh-76763: Make chr() always raising ValueError for out-of-range…
hauntsaninja commentedon Feb 4, 2024
Given that this is a long standing behaviour and there's little reason to be passing large values here, should we just document that
chrcan raise OverflowError?Also note
"%c" % 1114113raises OverflowError, should that raise ValueError instead?gh-76763: Make chr() always raising ValueError for out-of-range values (
vstinner commentedon Feb 12, 2024
To clarify for myself, with change e2c4038,
chr()no longer raisesOverflowError, but always raisesValueError.@serhiy-storchaka updated the old change on the main branch and merged it.
pythongh-76763: Make chr() always raising ValueError for out-of-range…