issue_comments

Table actions

2 rows where author_association = "CONTRIBUTOR" and issue = 557257598 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

issue 1

  • Repeated coordinates leads to unintuitive (broken?) indexing behaviour · 2 ✖

author_association 1

  • CONTRIBUTOR · 2 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1234643971 https://github.com/pydata/xarray/issues/3731#issuecomment-1234643971 https://api.github.com/repos/pydata/xarray/issues/3731 IC_kwDOAMm_X85JlywD delgadom 3698640 2022-09-01T18:36:30Z 2022-09-01T18:36:30Z CONTRIBUTOR

FWIW I could definitely see use cases for allowing something like this... I have used cumbersome/ugly workarounds to work with variance-covariance matrices etc. So I'm not weighing in on the "this should raise an error" debate. I got briefly excited when I saw it didn't raise an error, until everything started unraveling 🙃 

{
    "total_count": 2,
    "+1": 1,
    "-1": 0,
    "laugh": 1,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Repeated coordinates leads to unintuitive (broken?) indexing behaviour 557257598
1234639080 https://github.com/pydata/xarray/issues/3731#issuecomment-1234639080 https://api.github.com/repos/pydata/xarray/issues/3731 IC_kwDOAMm_X85Jlxjo delgadom 3698640 2022-09-01T18:31:08Z 2022-09-01T18:31:08Z CONTRIBUTOR

ooh this is a fun one! came across this issue when we stumbled across a pendantic case writing tests (H/T @brews). I expected this to "fail loudly in the constructor" but it doesn't. note that currently AFAICT you cannot use positional slicing to achieve an intuitive result - the behavior seems more undefined/unpredictable

```python

setup

import xarray as xr, pandas as pd, numpy as np da = xr.DataArray(np.arange(8).reshape(2, 2, 2), coords=[[0, 1], [0, 1], ['a', 'b']], dims=["ni", "ni", "shh"]) xarray seems to not know it has a problem:python In [4]: da Out[4]: <xarray.DataArray (ni: 2, shh: 2)> array([[[0, 1], [2, 3]],

   [[4, 5],
    [6, 7]]])

Coordinates: * ni (ni) int64 0 1 * shh (shh) <U1 'a' 'b' slicing (somewhat intuitively? slices along both dims):python In [5]: da.sel(ni=0) Out[5]: <xarray.DataArray (shh: 2)> array([0, 1]) Coordinates: ni int64 0 * shh (shh) <U1 'a' 'b' however, positional slicing (and any attempts I've made to handle the repeated dims differently) seems to have undefined behavior:python In [6]: da[0, :, :] # positional slicing along first dim works as expected(?) Out[6]: <xarray.DataArray (ni: 2, shh: 2)> array([[[0, 1], [2, 3]],

   [[4, 5],
    [6, 7]]])

Coordinates: * ni (ni) int64 0 1 * shh (shh) <U1 'a' 'b'

In [7]: da[:, 0, :] # positional slicing along second dim slices both dims Out[7]: <xarray.DataArray (shh: 2)> array([0, 1]) Coordinates: ni int64 0 * shh (shh) <U1 'a' 'b' ```

 
{
    "total_count": 2,
    "+1": 2,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Repeated coordinates leads to unintuitive (broken?) indexing behaviour 557257598

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);