This line (which contains a non-ASCII digit):

python3.9 -c "import datetime; datetime.date.fromisoformat('1963-06-1৪')"

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)

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.

The dupe was closed without a real conclusion but I think @pganssle's suggestion is what we should do here.

we're better off resolving the inconsistency by requiring ASCII digits and considering non-ASCII support to be a separate feature request

I'll implement it for fromisoformat to close this issue.