Files
RustPython/Lib
Jeong, YunWon 322f294a21 common: add VM-independent codec and text engines (#8622)
* common: add PyPy CJK codec engines

Assisted-by: Codex:GPT-5

* common: mark CJK mapping tables generated

Assisted-by: Codex:GPT-5

* common: add reusable byte and text engines

Assisted-by: Codex:GPT-5

* common: record opt-in engine dependencies

Assisted-by: Codex:GPT-5

* stdlib: add `_multibytecodec` and the six `_codecs_*` modules

Wire the CJK codec engines in `rustpython-common` up to the VM. `_multibytecodec`
holds `MultibyteCodec`, `MultibyteIncrementalEncoder`, `MultibyteIncrementalDecoder`,
`MultibyteStreamReader` and `MultibyteStreamWriter`, the encode/decode drivers and
the error-handler protocol; each `_codecs_*` module exposes `getcodec` for the
encodings of its region.

`rustpython-stdlib` now enables the `cjk-codecs` feature of `rustpython-common`.

Add `cjk::decode_reset`, which the decoder `reset()` methods need. It differs from
building a fresh decoder state: ISO 2022 keeps its G1..G3 designations and the
escape-throughout flag, and resets only G0 and the shifted flag.

Drop the markers from the CJK codec tests and from the `test_codecs`, `test_io`,
`test_email`, `test_zipfile` and `test_traceback` cases that needed a CJK codec.
`test_codecs.BasicUnicodeTest.{test_basics,test_decoder_state}` stay expected
failures for an unrelated reason: `codecs.charmap_encode` rejects a `None` mapping.

Assisted-by: Claude Code:claude-opus-5

* stdlib: use the byte and text engines from `rustpython-common`

`binascii`, `_json` and `_socket`'s address converters now call the engines in
`rustpython-common` instead of carrying their own copies, and `rustpython-stdlib`
enables the `binascii`, `inet` and `json` features for them. That leaves
`base64` and `crc32fast` with no caller in `rustpython-stdlib`, and
`crates/stdlib/src/json/machinery.rs`, the last of the json_in_type-derived code,
goes away with its last caller.

The address converters change behaviour. `inet_aton` reads the lenient forms
(`127.1`, `16909060`, `0x7f.1`, `0177.0.0.1`), `inet_pton` rejects an octet with a
redundant leading zero and a group of five hex digits, `inet_ntop` writes the
IPv4-compatible form as `::c000:201`, and an address family with no converter
raises `EAFNOSUPPORT` instead of a bare `OSError`.

Give the JSON engine the closing-quote scan and the allocation-free `\uXXXX`
escape it needs to carry `_json`'s workload. Against the code it replaces,
`json.dumps` runs 2.3x faster with `ensure_ascii=True` and 1.7x without it, and
`json.loads` 1.2x.

`binascii.a2b_base64` now reports the messages `binascii.c` does: no
`error decoding base64: ` prefix, and the data-character count in parentheses.

Assisted-by: Claude Code:claude-opus-5

* test: enable the Windows cp932 codec case

The shared CJK engine now satisfies the Windows code-page adapter, so keeping this test marked as an expected failure turns its success into a CI failure.

Assisted-by: Codex:GPT-5
2026-08-31 15:44:55 +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-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-24 01:07:30 +00:00
2026-01-30 16:38:36 +02: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-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-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-04 18:32:45 +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
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-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.