issues: 59323055

This data as json

id node_id number title user state locked assignee milestone comments created_at updated_at closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
59323055 MDU6SXNzdWU1OTMyMzA1NQ== 345 Alternatives to virtual variables in the form "time.season"? 1217238 closed 0     3 2015-02-28T03:32:55Z 2015-03-03T01:10:12Z 2015-03-02T23:20:07Z MEMBER      

@jhamman writes in #337:

Since ds.groupby('time.season').mean('time') returns a Dataset with a Coordinates variable named time.season, ds.sel(time.season='JJA') doesn't work for Python syntax reasons. So, I don't know if I would change the syntax used in my example (selecting my position). I'm not keen on this constructor: ds.sel(**{'time.season':'JJA'}). I'm wondering if it would be better to name the coordinates returned from "virtual variable" operations without the "time." portion. Just a thought.

I agree, this is awkward. This has been on my to-do list in the back of my head for some time.

My hesitation with just using 'season' for the name of ds['time.season'] is that it would be a little weird to have indexing return something with a different name than what you asked for.

ds['season'] is another optional that initially looks even more appealing, but what if we have more than datetime variable? This is not unheard of (e.g., 'time' and 'forecast_reference_time').

Another option would be to simply support ds['time_season']. Then at least you can do indexing without using ** (e.g., ds.sel(time_season='JJA')).

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/345/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   completed 13221727 issue

Links from other tables