@ninousf sorry for not following up earlier? Did you have a use-case beyond dropping metadata in .npy?
Otherwise, I am tempted to follow-up to use this here and consider this semi-private (which it effectively is).

Hi Sebastian
We can keep it in utils.py
My use case is to be able to copy a hdf5 file which contains arrays with dtypes containing metadata in a zarr file
See #1152

It looks a bit like we may add np.dtypes as a namespace (I am starting to assume we will have enough use for it). That is a bit annoying, because adding it here might be too much right now, so I can follow-up on it.

One thing I am wondering: I somewhat like the idea of adding the behavior:

• Check whether metadata is None ahead of time, if it is return the dtype unmodified (the identity).
• For a structured/subarray dtypes we would have to also return the identity if all fields/the subdtype and the dtype itself has no metadata.

That would allow us to do:

no_metadata = drop_metadata(dtype)
if no_metadata is not dtype:
    warnings.warn("Dropping metadata which cannot be stored in an npy/npz file", UserWarning)

Although, I am not sure we actually need the warning there, maybe it is useful to be able to know that a change happened?

@ninousf could you review my changes? I made some heavier changes to use this for np.save and np.savez and also just to make the code cleaner, IMO.

Now, I don't like np.lib.utils.drop_metadata as a home, so I added a fuzzy "this is somewhat public" comment, but 🤷.
I would have liked to put this into the new np.dtypes namespace. But the function really has some problems (poor record dtype and results are plain wrong for user dtypes). That fits OK with npy saving, which has the same problem, but makes me not want to put it there yet. We should find a proper solution (probably in C).

The new code is a bit more robust than the previous one, because it returns the original dtype when there is no metadata attached. So at least if no metadata is used things should be fine even for user dtypes.

@seberg it's ok for me, thanks

This could use a release note.

@ninousf This needs a release note. If you cannot add that today, I'm going to push this off to the next release.

@charris Tell me if it's ok for you

Looks fine, thanks.

Thanks @ninousf

Please consider marking this as fully public. Metadata is great to forego ndarray subclasses, but until this function came along, there was no good way to e.g. update a value in the metadata.

PS: Actually, maybe consider changing the order of the metadata update, so that all new_metadata survives in np.dtype(dtype, metadata=new_metadata).