assess Array / AsyncArray split?

[d-v-b]

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.

[TomNicholas]

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 .flush and .flush_async.

[d-v-b]

even we had flush and flush_async, the issue of two classes remains: Would it better to have 2 classes with methods AsyncArray.flush and Array.flush (which calls .async_array.flush() internally), or to have 1 class with flush and flush_async methods?

[TomNicholas]

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...