Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

data/coords alias #8054

Closed
LecrisUT opened this issue Aug 8, 2023 · 7 comments
Closed

data/coords alias #8054

LecrisUT opened this issue Aug 8, 2023 · 7 comments

Comments

@LecrisUT
Copy link

LecrisUT commented Aug 8, 2023

It would be nice to allow in dataset/dataarray to alias a coordinate/data. E.g. ds['time'] == ds['t']. This would be beneficial for midleware libraries to create more natural interface.

Implementation wise, this can be restricted to the indexers of the dataset/dataarray, and internally save a dictionary of aliases.

@welcome
Copy link

welcome bot commented Aug 8, 2023

Thanks for opening your first issue here at xarray! Be sure to follow the issue template!
If you have an idea for a solution, we would really welcome a Pull Request with proposed changes.
See the Contributing Guide for more.
It may take us a while to respond here, but we really value your contribution. Contributors like you help make xarray better.
Thank you!

@benbovy
Copy link
Member

benbovy commented Aug 8, 2023

If the goal is for a variable and its aliases to share the same underlying data, you could already do it (xarray Dataset is "just" a fancy dict-like container):

import numpy as np
import xarray as xr

arr = np.array([1, 2, 3])

ds = xr.Dataset({"foo": ("x", arr)})
ds["bar"] = ds["foo"]
ds.foo[0] = 4

print(ds)
# <xarray.Dataset>
# Dimensions:  (x: 3)
# Dimensions without coordinates: x
# Data variables:
#     foo      (x) int64 4 2 3
#     bar      (x) int64 4 2 3

This won't work with variable attributes and also likely neither with indexed coordinate variables, though.

internally save a dictionary of aliases

That could be possible, but I'm not sure the extra convenience it provides (for a few cases?) would be worth the extra cost in maintenance, complexity, etc. This could also be easily done externally IMHO.

@LecrisUT
Copy link
Author

LecrisUT commented Aug 8, 2023

Hmm, indeed that is quite neat. I don't like that it displays as a separate data so the fact that they are aliased is not obvious. But indeed I think this can be handled externally. Implementation wise that would mean to make a separate wrapper class for attrs and dataset and dataarray, unless, do you know of a method to inject/alter class definitions upon a module load?

@benbovy
Copy link
Member

benbovy commented Aug 8, 2023

Implementation wise that would mean to make a separate wrapper class for attrs and dataset and dataarray, unless, do you know of a method to inject/alter class definitions upon a module load?

I was rather thinking about just using a dictionary of name aliases like

aliases = {"t": "time"}

ds[aliases["t"]].identical(ds["time"])
# True

For a bit more convenience, you could create a Dataset accessor to get the original item from the alias name:

@xr.register_dataset_accessor("aliases")
class AliasesAccessor:
    def __init__(self, xarray_obj):
        self._obj = xarray_obj
        self._aliases = aliases
    
    def __getitem__(self, key):
        return self._obj[self._aliases[key]]
ds = xr.Dataset({"time": [1, 2, 3]})

ds.aliases["t"].identical(ds["time"])
# True

@LecrisUT
Copy link
Author

LecrisUT commented Aug 8, 2023

Thanks, that's really interesting. I'll think about how to design along those lines

@keewis
Copy link
Collaborator

keewis commented Aug 8, 2023

note that a big part of cf-xarray is basically that: a way to look up aliases using standardized metadata (ie. metadata following the CF conventions)

@dcherian
Copy link
Contributor

dcherian commented Aug 8, 2023

👍 cf-xarray seems like the way to go

@dcherian dcherian closed this as completed Aug 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants