fix(base): generate and hash Python stubs as UTF-8

DE
9d ago
+87-2

The stub generator relies on the locale encoding when writing .pyi files and reading them back for hashes. On Windows with a non-UTF-8 default, a component description containing • produces a CP1252 stub that Ruff cannot decode as UTF-8; characters outside that code page can instead raise UnicodeEncodeError. Merely fixing the writer still leaves hash computation decoding UTF-8 bytes with the wrong encoding.

Specify UTF-8 for both the generated stub and its hash input. Preserve the existing newline normalization and registry format. This changes two production lines and adds a reflex-base bugfix news fragment; no dependencies or public APIs change.

Validation:

  • Twelve end-to-end generation/hash cases exercise CP1252, ASCII, and UTF-8 defaults, Unicode prop documentation, and both registry replacement/merge modes. Eight fail before the fix; four UTF-8 controls pass. All twelve pass afterward. The tests check preserved Unicode, Python parsing of the generated bytes, and the final registry checksum.
  • Related generator, driver and published-stub verification suites: 128 passed on Windows / Python 3.14.
  • Full local stub regeneration with PYTHONUTF8=0 completed successfully; all generated files passed their formatting/fixup step, and the tracked hash manifest remained unchanged.
  • Applicable pre-commit hooks passed: Ruff format/lint, codespell, stub generation, Pyright and ty.

Generated stubs and hash manifests are excluded from the diff. No database/browser/provider integration was needed for this generator change. AI assistance: OpenAI Codex; submitted through DevChiniwala.

All Submissions

  • Followed the contribution guidelines and reviewed the patch.
  • Searched for competing PRs for this encoding problem.

Type of change

  • Bug fix.

Changes To Core Features

  • Explained the changed behavior and why it matters.
  • Added meaningful regression tests and ran related tests locally.