Files
RustPython/Lib/test
1f2f7ff012 Fix int unicode decimal digits (#8521)
* Accept Unicode decimal digits in int(), Decimal() and complex()

CPython runs a string argument through
_PyUnicode_TransformDecimalAndSpaceToASCII before parsing it, so decimal
digits from any script are accepted:

    int('١٢٣')          # 123
    int('0x١f', 16)     # 31
    Decimal('١٢٣')      # Decimal('123')
    complex('1+2j')    # (1+2j)

RustPython only did this for float(), which had the transform inlined.
int() handed the raw UTF-8 bytes to bytes_to_int(), whose digit check is
is_ascii_alphanumeric(), so every non-ASCII digit was rejected — even
though float() accepted the same string.

Lift the inlined transform out of float_from_string() into
common::str::transform_decimal_and_space_to_ascii() and apply it to the
str paths of int() and complex() too. The result is always ASCII: as in
CPython, a character that is neither ASCII, whitespace nor a decimal
digit becomes '?' and truncates the string, which no parser accepts at
any base, leaving the caller to raise the error from the original string.

Bytes-like input keeps going straight to the parser, matching CPython's
split between PyLong_FromUnicodeObject and PyLong_FromString.

This unmarks two expectedFailure tests: test_int.test_unicode and
test_decimal.test_unicode_digits.

* Share one PyStr-to-numeric-literal step across int, float and complex

All three constructors need the same thing from a str argument: trim it,
fold Unicode decimal digits and whitespace to ASCII, and give up on a
string holding surrogates. Each expressed that last part differently —
float matched PyKindStr and returned b"", complex leaned on to_str()
returning None, int returned an empty Cow — so the rule lived in three
places at once.

Move it into protocol::numeric_literal_from_str() and have all three call
it. CPython repeats this per type because its wrapper is three lines over
a single PyUnicode representation; ours has to match over Ascii/Utf8/Wtf8,
which is worth writing once.

Only the shared step moves. int keeps its base handling, int and float
keep accepting bytes-like input, complex keeps rejecting it, and each
keeps raising its own error, because none of that is shared.

No behavior change: the CPython differential suite is byte-identical
before and after.

* Drop the now-empty test_unicode_digits override in test_decimal

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Jeong, YunWon <69878+youknowone@users.noreply.github.com>
2026-08-18 22:24:02 +09:00
..
2026-03-01 11:36:46 +09:00
2025-08-24 10:36:07 +03:00
2023-04-20 15:36:28 +09:00
2023-03-02 15:01:12 +09:00
2026-05-24 19:56:35 +09:00
2026-02-05 00:21:34 +09:00
2022-10-18 03:26:29 +09:00
2026-05-12 20:51:33 +09:00
2023-03-01 18:06:50 +09:00
2026-03-01 11:36:46 +09:00
2026-02-02 02:02:12 +09:00
2026-02-13 22:15:52 +09:00
2026-01-25 15:20:05 +09:00
2026-05-24 19:56:35 +09:00
2026-08-03 17:52:42 +09:00
2026-02-13 13:36:33 +02:00
2026-02-13 14:13:30 +09:00
2024-06-24 19:00:54 +09:00
2026-02-11 16:50:23 +09:00
2026-02-08 20:36:35 +09:00
2026-02-10 00:48:22 +09:00
fix
2026-02-12 01:01:35 +09:00
2026-02-13 13:36:33 +02:00
2026-05-30 20:16:10 +09:00
2026-02-03 22:10:31 +09:00
2026-02-06 00:15:18 +09:00
2026-06-10 11:14:05 +09:00
2026-05-17 19:49:19 +09:00
2026-06-15 11:21:28 +09:00
2026-03-06 06:00:08 +09:00
2026-02-13 13:55:05 +09:00
2026-02-14 18:19:57 +02:00
2026-01-25 00:18:55 +09:00
2026-01-26 10:40:22 +09:00
2026-07-07 09:19:25 +09:00
2026-02-03 22:10:31 +09:00
2026-03-12 18:08:56 +09:00
2025-08-31 11:58:21 +03:00
2026-02-06 01:14:55 +09:00
2026-02-13 13:36:33 +02:00
2026-02-04 18:32:45 +09:00
2026-03-03 19:57:50 +09:00
2026-02-28 22:50:51 +09:00
2025-04-21 21:11:42 -07:00
2026-01-31 20:51:53 -05:00
2025-12-12 10:37:40 +09:00
2026-06-15 11:12:39 +09:00
2026-02-14 21:40:04 +09:00
2026-02-14 09:18:09 +09:00
2025-03-26 23:12:21 -05:00
2026-03-21 22:49:09 +09:00
2026-06-11 12:15:21 +09:00
2026-03-03 21:58:46 +09:00
2025-01-17 18:04:25 -08:00
2026-01-25 00:18:55 +09:00
2026-01-25 00:18:55 +09:00
2026-02-13 13:44:28 +09:00
2026-01-25 00:18:55 +09:00
2026-02-13 13:42:22 +09:00
2026-01-25 00:18:55 +09:00
2026-06-15 11:19:40 +09:00
2026-03-05 17:25:59 +09:00
2023-04-20 15:36:28 +09:00