Skip to content

Add typed Polars quantity frames#20

Merged
wlaur merged 16 commits into
mainfrom
feat/polars-unit-dtype
Jul 16, 2026
Merged

Add typed Polars quantity frames#20
wlaur merged 16 commits into
mainfrom
feat/polars-unit-dtype

Conversation

@wlaur

@wlaur wlaur commented Jul 16, 2026

Copy link
Copy Markdown
Owner

Summary

  • add a Polars extension dtype that persists unit metadata through Arrow and Parquet
  • add declarative QuantityFrame schemas with typed expression access, derivation, and Parquet scanning
  • integrate quantity frames with fluid expressions and document the end-to-end workflow
  • release as version 1.8.0

Validation

  • uv lock --check
  • ruff check and format check
  • pyright, pyrefly, and ty
  • 1056 tests passed
  • Sphinx build with warnings as errors

wlaur and others added 16 commits July 11, 2026 17:48
Evaluation prototype for IMPROVEMENT.md 1.1: UnitDType (pl.BaseExtension,
unit string normalized through the registry as dtype metadata) plus
with_units/units_of/quantities/dataframe helpers. Plain polars I/O
round-trips the dtype; unit algebra stays in Quantity, constructed from
unit-typed columns. Tests pin the round-trip and refusal semantics since
the upstream extension-type API is unstable.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011o88ZV5hHQHYRMDVWSzxu1
An extension-typed input column (e.g. the encomp.polars unit dtype)
panicked inside the plugin's FFI field import: the plugin build lacked
polars' dtype-extension feature, so from_arrow_field hit the
unsupported-dtype panic arm before any plugin code ran.

Enable dtype-extension (the plugin's own registry loads unknown
extension types as generic, never as bare storage, so the dtype arrives
intact) and validate inputs in the output-dtype callbacks and compute
entrypoints: an extension-typed input now fails at schema-resolution
time with an actionable message naming the input and suggesting
`.ext.storage()` after SI conversion. Silently using the storage values
was not an option -- it could treat e.g. bar as Pa. The Cargo.lock
growth is the feature's transitive polars-expr/polars-dtype tree.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011o88ZV5hHQHYRMDVWSzxu1
An "encomp.unit" extension-typed input whose unit is already the SI unit
CoolProp expects now passes straight through the plugin (storage values
used as-is); any other unit is refused at schema-resolution time with
both units named. No unit table is duplicated anywhere: the wrappers
derive the expected unit from CoolProp's own parameter metadata
(get_parameter_information) for fluid inputs and from the existing
HumidAir.get_coolprop_unit mapping for humid air, normalized through the
registry -- the same canonicalization the unit dtype applies to its
metadata, so the plugin's check is plain string equality. The Float32
output rule looks through the extension dtype to its storage.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011o88ZV5hHQHYRMDVWSzxu1
…tting

End-to-end review of the SI-match acceptance found one real defect:
canonicalization went through str(Unit(...)), which follows the
process-wide display format. After set_quantity_format("siunitx"), the
dtype metadata would be written as LaTeX and the plugin's unit
comparison would drift with a display setting. Both sides now use
encomp.polars.canonical_unit_string (fixed "~P": "m³/h", "°C" --
identical to the default rendering, so nothing already written changes).
Regression tests pin the metadata rendering and the plugin match under
a non-default display format, plus a Parquet-scan end-to-end through
the plugin on both engines.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011o88ZV5hHQHYRMDVWSzxu1
@wlaur
wlaur merged commit 4952c4a into main Jul 16, 2026
19 checks passed
@wlaur
wlaur deleted the feat/polars-unit-dtype branch July 16, 2026 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant