Right now our FillValue class is a very minimal wrapper of upstream Zarrs FillValue, which holds only a raw Vec<u8>.
Perhaps our FillValue should also hold a DataType so that it can be smarter about the user-facing API it presents?
Like it could have a to_numpy API that would then create a np.uint8(value) or np.float32(value) etc.
Then the user wouldn't have to manually convert raw bytes into a specific data type's fill value.
This would change our Python-facing FillValue to be fully generic to being tied to a specific array's data type, but I think that's an improvement in ergonomics.
Right now our
FillValueclass is a very minimal wrapper of upstream ZarrsFillValue, which holds only a rawVec<u8>.Perhaps our
FillValueshould also hold aDataTypeso that it can be smarter about the user-facing API it presents?Like it could have a
to_numpyAPI that would then create anp.uint8(value)ornp.float32(value)etc.Then the user wouldn't have to manually convert raw bytes into a specific data type's fill value.
This would change our Python-facing
FillValueto be fully generic to being tied to a specific array's data type, but I think that's an improvement in ergonomics.