Skip to content

Rename chunk_dim to stream_dim, following ezmsg core - #16

Merged
cboulay merged 1 commit into
devfrom
cboulay/stream-dim
Sep 9, 2026
Merged

cboulay merged 1 commit into
devfrom
cboulay/stream-dim

Conversation

@cboulay

@cboulay cboulay commented Sep 9, 2026

Copy link
Copy Markdown
Member

Tracks the rename of AxisArray.chunk_dim to stream_dim in ezmsg core (ezmsg-org/ezmsg#265).

Why the name changed

chunk was already spoken for in three directions:

  • xarray, dask, zarr, HDF5 all use chunk for multi-dimensional memory/IO layout. Since AxisArray deliberately echoes xarray.DataArray — which has a .chunk() method — borrowing the word invites exactly the wrong reading.
  • ezmsg itself already uses it a second way: array_chunker / chunk_len mean "how much data per message".
  • Neither is what the field says. It names the dimension the stream extends along — the one whose extent is arbitrary because successive messages append there.

stream_dim names that role directly and reuses ezmsg's own vocabulary (InputStream / OutputStream). append_dim (zarr) and concat_dim (xarray) were the closest semantic matches but were rejected: in ezmsg-sigproc those words already name the target argument of an append or concat operation. netCDF's unlimited_dims describes a static property of the dimension rather than what is happening to it.

What's in here

Pure rename — no behaviour change.

util/chunkdim.py becomes util/streamdim.py, and the two exported helpers are renamed with it:

before after
resolve_chunk_dim resolve_stream_dim
resolve_configured_chunk_dim resolve_configured_stream_dim

STREAMING_DIMS, resolve_feature_dim and resolve_transform_dim keep their names. Neither renamed helper has ever been published — the latest tag is v1.12.0, which predates the module — so no released API breaks.

Uses of chunk that mean how much data a message carries are deliberately left alone; only the dimension sense is renamed, including the prose that describes it.

The ezmsg floor moves >=3.10.0b2 → >=3.10.0b3. 3.10.0b1 and b2 are on PyPI carrying chunk_dim, so the floor has to move for the rename to be meaningful; 3.10.0b3 is the first release with stream_dim.

Testing

239 passed, 1 skipped, run against the renamed ezmsg core and ezmsg-baseproc installed editable.

Merge order: ezmsg 3.10.0b3 must be on PyPI before this merges, or CI here resolves an ezmsg that has no stream_dim.

Tracks the upstream rename of `AxisArray.chunk_dim`. `chunk` collided
three ways: xarray's `DataArray.chunk`, dask, zarr and HDF5 all use it for
memory/IO layout, and ezmsg's own `array_chunker` / `chunk_len` mean "how
much data per message". `stream_dim` names the role instead -- the
dimension the stream extends along.

`util/chunkdim.py` becomes `util/streamdim.py`, `resolve_chunk_dim` and
`resolve_configured_chunk_dim` become `resolve_stream_dim` and
`resolve_configured_stream_dim`. `STREAMING_DIMS`, `resolve_feature_dim`
and `resolve_transform_dim` keep their names.

Prose describing "chunk size" -- how much data a message carries, in
clockdriven and counter -- is left alone; that is the other meaning of the
word and it is the correct one there.

Pure rename. 239 passed, 1 skipped.
@cboulay
cboulay merged commit a0a3c61 into dev Sep 9, 2026
15 of 40 checks passed
@cboulay
cboulay deleted the cboulay/stream-dim branch September 9, 2026 04:21
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