Repository navigation
Closed
Labels
3.13only security fixesonly security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Description
| BPO | 32582 |
|---|---|
| Nosy | @terryjreedy, @mdickinson, @vstinner, @serhiy-storchaka, @iritkatriel |
| PRs | |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2018-01-17.14:32:06.372>
labels = ['interpreter-core', 'type-bug', '3.11']
title = 'chr raises OverflowError'
updated_at = <Date 2021-11-22.15:20:54.228>
user = 'https://bugs.python.org/ukl'bugs.python.org fields:
activity = <Date 2021-11-22.15:20:54.228>
actor = 'mark.dickinson'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2018-01-17.14:32:06.372>
creator = 'ukl'
dependencies = []
files = ['47390']
hgrepos = []
issue_num = 32582
keywords = ['patch']
message_count = 5.0
messages = ['310178', '310180', '310288', '310330', '406721']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'mark.dickinson', 'vstinner', 'serhiy.storchaka', 'ukl', 'iritkatriel']
pr_nums = ['5218']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue32582'
versions = ['Python 3.11']Linked PRs
Metadata
Metadata
Assignees
Labels
3.13only security fixesonly security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
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…