mirror of
https://github.com/RustPython/RustPython.git
synced 2026-10-29 03:04:38 +08:00
Joshua Megnauth
c8f1ab7fbc
* ucd: Parse Unihan data for 3.2.0; unmask test Python's 3.2.0 path uses the Unihan data for supplementary numeric values. The Unihan data isn't bundled with the "full" data which means we have to parse it ourselves. The full data is large, so I compressed it with zlib. AI disclosure: I asked an LLM to elaborate on why the full Unicode 3.2.0 data precludes \u5793. It explained that the code point is part of Unihan. I wrote the parser myself. I linted the zlib snippet with AI. Assisted-by: GPT-5.6: Luna * Use spare_capacity_mut + set_len over transmute
28 lines
784 B
TOML
28 lines
784 B
TOML
[package]
|
|
name = "rustpython-unicode"
|
|
description = "Runtime-independent CPython-compatible Unicode semantics and data for RustPython and related Python tooling."
|
|
edition = { workspace = true }
|
|
version = { workspace = true }
|
|
authors = { workspace = true }
|
|
repository = { workspace = true }
|
|
license = { workspace = true }
|
|
rust-version = { workspace = true }
|
|
|
|
[dependencies]
|
|
rustpython-wtf8 = { workspace = true }
|
|
|
|
icu_casemap = { workspace = true }
|
|
icu_locale = { workspace = true }
|
|
icu_properties = { workspace = true }
|
|
icu_normalizer = { workspace = true }
|
|
unicode_names2 = { workspace = true }
|
|
writeable = { workspace = true }
|
|
|
|
[build-dependencies]
|
|
icu_properties = { workspace = true }
|
|
unicode_names2 = { workspace = true }
|
|
zlib-rs = { workspace = true }
|
|
|
|
[lints]
|
|
workspace = true
|