Repository navigation
datetime's C implementation verifies fromisoformat is ASCII, but the pure python implementation does not #89157
Description
| BPO | 44994 |
|---|---|
| Nosy | @Julian, @pganssle |
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 2021-08-24.20:32:18.922>
labels = ['type-bug', '3.8', '3.9', '3.10', '3.11', '3.7', 'library']
title = "datetime's C implementation verifies fromisoformat is ASCII, but the pure python implementation does not"
updated_at = <Date 2021-08-24.20:32:18.922>
user = 'https://github.com/Julian'bugs.python.org fields:
activity = <Date 2021-08-24.20:32:18.922>
actor = 'Julian'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-08-24.20:32:18.922>
creator = 'Julian'
dependencies = []
files = []
hgrepos = []
issue_num = 44994
keywords = []
message_count = 1.0
messages = ['400235']
nosy_count = 2.0
nosy_names = ['Julian', 'p-ganssle']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue44994'
versions = ['Python 3.7', 'Python 3.8', 'Python 3.9', 'Python 3.10', 'Python 3.11']
Activity
Julian commentedon Aug 24, 2021
This line (which contains a non-ASCII digit):
raises:
Traceback (most recent call last): File "<string>", line 1, in <module> ValueError: Invalid isoformat string: '1963-06-1৪'under the C implementation of the datetime module, but when the pure Python implementation is the one imported, succeeds (and produces
datetime.date(1963, 6, 14))The pure Python implementation should instead explicitly check and raise when encountering a non-ASCII string.
(On PyPy, which always uses the pure-Python implementation, this contributes to a behavioral difference)
lucasalavapena commentedon Mar 1, 2023
I was able to reproduce this.
A Related issue is https://bugs.python.org/issue39280 (on GH #83461), there is an extensive discussion on there. Based on the discussion in that issue, unicode characters were deemed fine by @pganssle . The main problem is the inconsistency between the C and python implementation. I could try making a PR so that the C implementation can accept unicode character, if @pganssle think that is a good idea.
StanFromIreland commentedon Mar 9, 2025
The dupe was closed without a real conclusion but I think @pganssle's suggestion is what we should do here.
I'll implement it for fromisoformat to close this issue.
gh-89157: Make C and Python implementation of `datetime.date.fromisof…