issue_comments

Table actions

9 rows where user = 8078968 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 1

  • jbrockmendel · 9 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
903141020 https://github.com/pydata/xarray/issues/5721#issuecomment-903141020 https://api.github.com/repos/pydata/xarray/issues/5721 IC_kwDOAMm_X8411Nac jbrockmendel 8078968 2021-08-21T16:28:07Z 2021-08-21T16:28:07Z NONE

The "if method is not None" approach seems reasonable. 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   pandas deprecates Index.get_loc with method 975385095
847418464 https://github.com/pydata/xarray/issues/5287#issuecomment-847418464 https://api.github.com/repos/pydata/xarray/issues/5287 MDEyOklzc3VlQ29tbWVudDg0NzQxODQ2NA== jbrockmendel 8078968 2021-05-24T23:25:56Z 2021-05-24T23:25:56Z NONE

Unfortunately, pandas-dev/pandas#35032 was closed

I'm hoping to re-open at some point. The trouble I ran into is that a) there isn't any way to implement __array_function__ incrementally and b) there aren't any assurances on where self is among the args and kwargs passed to __array_function__. The workarounds I came up with for the latter were pretty ugly. Input would be welcome.

Keep in mind that PR implemented __array_function__ for NDArrayBackedExtensionArray (includes DatetimeArray, TimedeltaArray, PeriodArray, Categorical (and i expect most 3rd party EAs will be natural candidates)). Implementing it on the base ExtensionArray class would be a different animal.

Support N-D data, on top of pandas' 1D API. This would make extension arrays more generally useful in Xarray, but some operations might be hard to do efficiently

ATM NDArrayBackedExtensionArray explicitly supports 2D, and because it is a thin wrapper around np.ndarray higher-dimensions should either work or be within spitting distance of working.

I'm trying to get support for 2D more generally (xref https://github.com/pandas-dev/pandas/pull/38992), but at best it will be a while before that becomes a reality.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Support for pandas Extension Arrays 884649380
602090721 https://github.com/pydata/xarray/issues/3751#issuecomment-602090721 https://api.github.com/repos/pydata/xarray/issues/3751 MDEyOklzc3VlQ29tbWVudDYwMjA5MDcyMQ== jbrockmendel 8078968 2020-03-21T19:21:58Z 2020-03-21T19:21:58Z NONE

Can you open a pandas PR for the cftime-nearest-fix branch, and add a test in tests/test_downstream.py for the problematic behavior? That branch won't be merged as-is, but it will be easier to discuss options in-line.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   more upstream-dev cftime failures 559873728
599686613 https://github.com/pydata/xarray/issues/3751#issuecomment-599686613 https://api.github.com/repos/pydata/xarray/issues/3751 MDEyOklzc3VlQ29tbWVudDU5OTY4NjYxMw== jbrockmendel 8078968 2020-03-16T18:11:11Z 2020-03-16T18:11:11Z NONE

We're making progress on pandas-dev/pandas#32684, I'd also like to see if we can do an in-pandas fix to avoid the need to override more things here (i.e. #3764). Seems like that will lead to fewer headaches long-term.

Since pandas-dev/pandas#31511, the method has been updated to remove an np.asarray call, and I'm curious if that is enough to make #3764 unnecessary. The only remaining difference AFAICT is np.abs vs abs, which seems like it shouldnt be too tough to resolve.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   more upstream-dev cftime failures 559873728
597246745 https://github.com/pydata/xarray/issues/3751#issuecomment-597246745 https://api.github.com/repos/pydata/xarray/issues/3751 MDEyOklzc3VlQ29tbWVudDU5NzI0Njc0NQ== jbrockmendel 8078968 2020-03-10T18:36:34Z 2020-03-10T18:36:34Z NONE

@spencerkclark can you open an issue on the pandas tracker about this and ping me there; I dont want this to fall off my radar

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   more upstream-dev cftime failures 559873728
592583362 https://github.com/pydata/xarray/issues/3751#issuecomment-592583362 https://api.github.com/repos/pydata/xarray/issues/3751 MDEyOklzc3VlQ29tbWVudDU5MjU4MzM2Mg== jbrockmendel 8078968 2020-02-28T16:13:12Z 2020-02-28T16:13:12Z NONE

Do you think an upstream fix would be acceptable here?

Definitely. Is it still the case that the identified problems would all be solved by having is_scalar recognize cftime.datetime?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   more upstream-dev cftime failures 559873728
587572443 https://github.com/pydata/xarray/issues/3751#issuecomment-587572443 https://api.github.com/repos/pydata/xarray/issues/3751 MDEyOklzc3VlQ29tbWVudDU4NzU3MjQ0Mw== jbrockmendel 8078968 2020-02-18T17:14:55Z 2020-02-18T17:14:55Z NONE

Could there be a simple upstream fix for this?

Yah, pandas recently added a check for is_scalar(key) in Series.__getitem__ to try to avoid some unnecessary lookups. That will need to be changed to accommodate unexpected scalars.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   more upstream-dev cftime failures 559873728
582979076 https://github.com/pydata/xarray/issues/3751#issuecomment-582979076 https://api.github.com/repos/pydata/xarray/issues/3751 MDEyOklzc3VlQ29tbWVudDU4Mjk3OTA3Ng== jbrockmendel 8078968 2020-02-06T16:09:30Z 2020-02-06T16:09:30Z NONE

xarray/coding/cftimeindex.py:444: in __sub__ return CFTimeIndex(np.array(self) - other)

any idea what other is here? looks like it might be a DatetimeIndex

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   more upstream-dev cftime failures 559873728
574271673 https://github.com/pydata/xarray/issues/3673#issuecomment-574271673 https://api.github.com/repos/pydata/xarray/issues/3673 MDEyOklzc3VlQ29tbWVudDU3NDI3MTY3Mw== jbrockmendel 8078968 2020-01-14T16:56:34Z 2020-01-14T16:56:34Z NONE

we recently changed datetimelike arithmetic to send all object-dtype arrays through _addsub_object_array (previously _addsub_offsetlike). Previously I think idx.__add__(a) would return NotImplemented. So we probably want to get the NotImplemented behavior back.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Test failures with pandas master 547012915

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]);