Skip to content

Adopt MortonWord at scalar morton-return sites (deferred half of the option-(B) ruling)Β #215

Description

@espg

πŸ€– from Claude

Filed at espg's direction (in-session 2026-08-24, the option-(B) ruling on the #152/#176 standing questions): the irreversible pieces of the MortonWord design β€” the name, the flat export, the base_cell accessor spelling, and strict .decimal/.order β€” land before the 1.0 freeze on PR #212; the reversible piece is deferred here to 1.1:

Adoption at scalar morton-return sites. Every public function returning a single morton word as a scalar (decimal_to_word, the scalar arms of norm2mort/common_ancestor/moc_min, time-independent word producers β€” the "morton returns only" scope of the 2026-08-19 ruling: never times, orders, or uniq ids) returns MortonWord instead of bare np.uint64. This is compatible-by-construction (subclass substitution: isinstance passes, arithmetic demotes to bare np.uint64 β€” pinned by PR #212's tests; only repr output changes), which is exactly why it can ride 1.x as a minor rather than gating the freeze.

Scope for the PR that takes this: the return-site sweep, doctest/notebook output refresh (reprs become decimal labels), a display-cost sanity check on the scalar path (batch paths return arrays and are untouched), and the docs sweep updating return-type annotations. Plus any residual fixups the rename leaves behind.

Refs: #152 (the ruled design + PR #212), #176/PR #214 (the docs pin that will enforce the surface), #187/PR #195 (phase 6's uint64 unification this supersedes at scalar sites).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions