issues

Table actions

1 row where state = "open", type = "issue" and user = 941907 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

type 1

  • issue · 1 ✖

state 1

  • open · 1 ✖

repo 1

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
2275107296 I_kwDOAMm_X86Hm2Hg 8992 (i)loc slicer specialization for convenient slicing by dimension label as `.loc('dim_name')[:n]` smartass101 941907 open 0     0 2024-05-02T10:04:11Z 2024-05-02T14:47:09Z   NONE      

Is your feature request related to a problem?

Until PEP 472, I'm sure we would all love to be able to do indexing with labeled dimension names inside brackets. Here I'm proposing a slightly modified syntax which is possible to implement and would be quite convenient IMHO.

Describe the solution you'd like

This is inspired by the Pandas .loc(axis=n) specialization. Essentially the .(i)loc accessors would become callable like in Pandas, which would enable to specify the desired order of dimensions in the subsequent slicing brackets. Schematically ```python darr.loc('dim name 1', 'dim name 2')[x1:x2,y1:y2]

is equivalent to first returning an augmented `_LocIndexer` which now associates positional indexes to according to the provided dim orderpython loc_idx_spec = darr.loc('dim name 1', 'dim name 2') loc_idx_spec[x1:x2,y1:y2] `` The first part is essentially similar to.transpose('dim name 1', 'dim name 2')and in the case of aDataArray` it could be used instead. But this syntax could work also for Dataset. Additonally, it does not require an actual transpose operation.

This accessor becomes especially convenient when you quickly want to index just one dimension such as python darr.loc('dim name')[:x2]

Describe alternatives you've considered

The equivalent darr.sel({'dim name 1': slice(x1, x2), 'dim name 2': slice(y1,y2)}) is admittedly not that much worse, but for me writing slice feels cumbersome especially in situations when you have a lot of None specifications such as slice(None,None,2).

Additional context

This .loc(axis=n) API is (not so obviously) documented for Pandas here.

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

Advanced export

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

CSV options: 

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);