Files
RustPython/Lib
fdd101b896 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-06-12 11:10:50 +09:00
2026-05-17 20:54:56 +09:00
2026-06-15 11:21:28 +09:00
2026-05-12 00:42:54 +09:00
2026-01-20 15:29:05 +09:00
2026-01-17 19:21:11 +09:00
2026-05-12 20:52:36 +09:00
2026-06-15 11:20:13 +09:00
2026-06-15 11:19:40 +09:00
2026-06-15 11:19:40 +09:00
2026-05-20 23:09:50 +09:00
2025-03-20 14:28:26 +09:00
2025-03-10 11:43:53 +09:00
2026-02-02 01:20:23 +09:00
2025-01-11 18:48:27 +09:00
2025-03-10 11:43:53 +09:00
2025-03-10 23:13:32 -07:00
2026-02-13 13:55:05 +09:00
2026-02-24 01:07:30 +00:00
2026-01-30 19:21:10 +09:00
2026-02-02 01:20:23 +09:00
2026-02-28 12:09:59 +09:00
2026-01-31 10:11:58 +09:00
2025-04-21 20:45:06 -07:00
2026-01-24 00:24:12 +09:00
2026-02-18 00:43:49 +09:00
2026-02-24 01:07:30 +00:00
2026-01-30 16:38:36 +02:00
2026-02-08 20:36:35 +09:00
2026-01-26 10:40:22 +09:00
2026-02-11 16:47:03 +09:00
2025-04-30 14:33:52 +09:00
2026-01-30 07:48:29 +09:00
2026-02-08 16:35:56 +09:00
2026-02-08 16:35:56 +09:00
2026-02-14 21:40:04 +09:00
2026-02-15 21:04:32 +09:00
2026-05-12 20:53:24 +09:00
2026-02-13 14:13:30 +09:00
2026-02-09 12:56:53 +09:00
2026-02-14 18:19:57 +02:00
2026-01-21 20:14:30 +09:00
2026-01-25 00:18:55 +09:00
2026-03-01 14:51:54 +09:00
2026-01-23 23:57:31 +09:00
2026-06-11 13:36:30 +09:00
2026-05-17 19:49:42 +09:00
2026-03-03 20:00:50 +09:00
2026-03-12 18:08:56 +09:00
2026-02-13 20:24:57 +09:00
2026-02-06 01:14:55 +09:00
2026-05-12 20:51:02 +09:00
2025-07-25 10:50:17 +09:00
2026-02-13 18:07:25 +09:00
2026-02-04 18:32:45 +09:00
2026-05-17 19:49:09 +09:00
…
2026-01-21 15:10:40 +09:00
2026-05-12 20:51:46 +09:00
2025-04-21 21:11:42 -07:00
2025-07-17 00:04:12 +09:00
2024-04-26 01:39:02 +09:00
2026-05-12 00:43:34 +09:00
2026-05-12 20:51:57 +09:00
2026-05-13 19:52:56 +09:00
2024-03-22 14:54:02 +09:00
2024-03-22 14:54:02 +09:00
2026-03-01 11:36:46 +09:00
2026-02-14 09:18:09 +09:00
2026-02-11 18:01:41 +09:00
2026-01-21 03:05:05 +09:00
2026-01-30 19:13:59 +02:00
…
2026-05-12 20:53:11 +09:00
2026-01-22 08:02:43 +09:00
2026-03-10 11:28:16 +09:00
2026-03-04 05:38:58 +09:00
2026-06-03 18:36:37 +09:00
2026-06-15 11:20:13 +09:00
2026-06-15 11:20:13 +09:00
2026-06-02 18:00:54 +09:00
2026-02-13 13:42:22 +09:00
2026-01-30 19:21:10 +09:00
2026-03-05 17:25:59 +09:00

Standard Library for RustPython

This directory contains all of the Python files that make up the standard library for RustPython.

Most of these files are copied over from the CPython repository (the 3.7 branch), with slight modifications to allow them to work under RustPython. The current goal is to complete the standard library with as few modifications as possible. Current modifications are just temporary workarounds for bugs/missing feature within the RustPython implementation.

The first big module we are targeting is unittest, so we can leverage the CPython test suite.