Skip to content

Rename chunk_dim to stream_dim, following ezmsg core - #242

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.

Also follows ezmsg-baseproc's resolve_chunk_dim / resolve_configured_chunk_dim → resolve_stream_dim / resolve_configured_stream_dim (ezmsg-org/ezmsg-baseproc#16), and renames tests/unit/test_chunk_dim_resolution.py.

This package is the strongest case for the rename: it uses chunk heavily in the other sense — chunk_sizes in the MLX Metal kernels, chunk_len, "chunk-size jitter" — so the two meanings were colliding inside single files. Those are untouched.

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

4336 passed, 9 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` and the corresponding
`ezmsg.baseproc.util.streamdim` helpers. `chunk` was overloaded: xarray's
`DataArray.chunk`, dask, zarr and HDF5 all use it for memory/IO layout,
and this package uses it a third way -- `chunk_sizes`, `chunk_len`, "chunk
size jitter" -- for how much data a message carries. `stream_dim` names
the role instead: the dimension the stream extends along.

Those payload-size uses are deliberately left as `chunk`. Only the
dimension sense is renamed, including the prose that describes it ("chunk
dimension" / "chunk axis") and `test_chunk_dim_resolution.py`.

Pure rename. 4336 passed, 9 skipped, against the renamed ezmsg core and
ezmsg-baseproc.
@cboulay
cboulay merged commit 1a90a5b into dev Sep 9, 2026
14 of 38 checks passed
@cboulay
cboulay deleted the cboulay/stream-dim branch September 9, 2026 05:17
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