Repository navigation
assess Array / AsyncArray split? #3782
Description
Quick poll for anyone who has messed around with the internals of zarr.core.Array (synchronous IO methods) and zarr.core.AsyncArray (asynchronous IO methods, wrapped by zarr.core.Array): do you consider the use of two classes here useful and intuitive? Or would it be simpler to have a single class, with both async and sync methods?
Not to bias the results but I'm in the "1 class is simpler than 2 classes" camp.
Activity
TomNicholas commentedon Mar 16, 2026
I think the problem is more that there is no concept of "flushing". Its never very clear whether a zarr API call will immediately be reflected on disk or not. If all changes were staged, then only written with
.flush, then all you need is.flushand.flush_async.d-v-b commentedon Mar 16, 2026
even we had
flushandflush_async, the issue of two classes remains: Would it better to have 2 classes with methodsAsyncArray.flushandArray.flush(which calls.async_array.flush()internally), or to have 1 class withflushandflush_asyncmethods?TomNicholas commentedon Mar 16, 2026
An array is not async, only operations on that array are async (whether or not you queue them up, as you fairly point out). So I guess I'm on team 1 array class.
But I'm also not sure if this is a useful refactor to spend time on at this point...