asyncgroup.delitem silently fails if the key is missing

[d-v-b]

this should raise a keyerror. instead it silently does nothing.

# /// script
# requires-python = ">=3.11"
# dependencies = ["zarr"]
# ///

import zarr
store = {}
z = zarr.create_group(store)
del z['i do not exist']

[paraseba]

Sometimes the current behavior is useful. The HTTP protocol, and many others, define deletes as idempotent, so deleting twice, sequentially, an existing key should result in the same response each time. In a sense, when you delete something that is not there, the server is not wrong if it responds with "it was deleted".

This idempotency property is particularly useful in concurrent workflows.

I don't oppose to changing the behavior, but we should make sure it's an improvement.

[d-v-b]

you raise a good point about the advantages of idempotent deletes. I was expecting that people used to python dict-style semantics would consider it surprising that del would not raise a KeyError here. But if people don't find the current behavior weird, then we can leave this as-is.

[jhamman]

Zarr 2 raised a KeyError and I'll argue that we should go back to that behavior. If you want idempotent deletes from the dict-like interface, use Group.pop(key, None).

[paraseba]

Are there any Zarr stores that couldn't implement this behavior? For example, because of the property I mentioned above, an HTTP store probably cannot fail on missing key deletes efficiently (or consistently).

[jhamman]

Today, Zarr's HTTP stores don't support writes or deletes of any kind.