issue_comments: 290165548

This data as json

html_url issue_url id node_id user created_at updated_at author_association body reactions performed_via_github_app issue
https://github.com/pydata/xarray/issues/1092#issuecomment-290165548 https://api.github.com/repos/pydata/xarray/issues/1092 290165548 MDEyOklzc3VlQ29tbWVudDI5MDE2NTU0OA== 1217238 2017-03-29T17:38:03Z 2017-03-29T17:38:49Z MEMBER

The background flux is defined to be uniform in some coordinates, so it is lower-dimensionality than the total flux. It doesn't make sense to turn a 1-D variable into a 3-D variable just to match the others so I can put it into an array.

Yes, totally agreed, and I've encountered similar cases in my own work. These sort of "ragged" arrays are great use case for groups.

Accessing via ds['flux','poloidal'] is a bit confusing because ds[] is (I think) a dictionary, but supplying multiple names is suggestive of either array indexing or getting a list with two things inside, flux and poloidal. That is, the syntax doesn't reflect the semantics very well.

Yes, it's a little confusing because it looks similar to ds[['flux','poloidal']], which has different meaning. But otherwise programmatic access starts turning into a mess of string manipulation, e.g., ds['flux', subgroup] rather than ds['flux/' + subgroup].

If I am at the console, and I start typing ds.flux and use the tab-completion, does that end up creating a new dataset just so I can see what is inside ds.flux? Is that an expensive operation?

Yes, it would create a new dataset, which could take ~1 ms. That's slow for inner loops (though we could add caching to help), but plenty fast for interactive use.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   187859705