issue_comments

Table actions

6 rows where author_association = "MEMBER" and issue = 840258082 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

issue 1

  • `lock` kwarg needs a deprecation cycle? · 6 ✖

author_association 1

  • MEMBER · 6 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
831987634 https://github.com/pydata/xarray/issues/5073#issuecomment-831987634 https://api.github.com/repos/pydata/xarray/issues/5073 MDEyOklzc3VlQ29tbWVudDgzMTk4NzYzNA== TomNicholas 35968931 2021-05-04T14:31:10Z 2021-05-04T14:31:10Z MEMBER

No worries @alexamici ! I've merged your PR and it automatically closed this one.

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   `lock` kwarg needs a deprecation cycle? 840258082
831700309 https://github.com/pydata/xarray/issues/5073#issuecomment-831700309 https://api.github.com/repos/pydata/xarray/issues/5073 MDEyOklzc3VlQ29tbWVudDgzMTcwMDMwOQ== alexamici 226037 2021-05-04T05:57:19Z 2021-05-04T05:57:19Z MEMBER

Sorry for being so late to the party! I thought @aurghs did respond to this issue and forgot about it.

What has happened is not that lock (and group for the matter) disappeared altogether, but it has been moved to be a backend specific keyword argument. As far as I can see most internal backends still support it as before: cfgrib, netcdf4, pseudonetcdf, pynio and scipy.

The main difference is that lock was silently ignored by backend that don't support it like zarr and pydap.

The solution is to in fact only advertise the deprecation for those backends in my opinion as the functionality is legit for most of the backends.

Sorry again for seeing this so late.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   `lock` kwarg needs a deprecation cycle? 840258082
822129372 https://github.com/pydata/xarray/issues/5073#issuecomment-822129372 https://api.github.com/repos/pydata/xarray/issues/5073 MDEyOklzc3VlQ29tbWVudDgyMjEyOTM3Mg== dcherian 2448579 2021-04-19T02:46:06Z 2021-04-19T02:46:06Z MEMBER

We should fix this before the next release.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   `lock` kwarg needs a deprecation cycle? 840258082
807145690 https://github.com/pydata/xarray/issues/5073#issuecomment-807145690 https://api.github.com/repos/pydata/xarray/issues/5073 MDEyOklzc3VlQ29tbWVudDgwNzE0NTY5MA== keewis 14808389 2021-03-25T17:29:57Z 2021-03-25T17:30:57Z MEMBER

as far as I understand the docs of DeprecationWarning and FutureWarning, the main difference is the intended target audience in a traditional library vs. application setting (where libraries are always used to write applications): PendingDeprecationWarning and DeprecationWarning are used to signal deprecations in the library, while FutureWarning are intended for users of the application. Interestingly, PEP565 mentions that FutureWarning can also be used for changed semantics of valid code.

If we follow that, xarray should not issue FutureWarning (other than to report changing semantics) because it is a library and both interactive and scripted use would be similar to writing a application.

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   `lock` kwarg needs a deprecation cycle? 840258082
806944421 https://github.com/pydata/xarray/issues/5073#issuecomment-806944421 https://api.github.com/repos/pydata/xarray/issues/5073 MDEyOklzc3VlQ29tbWVudDgwNjk0NDQyMQ== fmaussion 10050469 2021-03-25T15:24:32Z 2021-03-25T15:24:32Z MEMBER

I think it's a DeprecationWarning since we're removing it rather than changing its behavior

Ha! I'm no expert either. I learned one thing recently though: DeprecationWarnings are silenced by python per default when not raised directly from __main__ and are therefore invisible for many users.

https://stackoverflow.com/questions/66590950/deprecationwarning-is-not-raised-on-import

https://stackoverflow.com/questions/55377831/difference-between-deprecationwarning-pendingdeprecationwarning-and-futurewarni 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   `lock` kwarg needs a deprecation cycle? 840258082
806243997 https://github.com/pydata/xarray/issues/5073#issuecomment-806243997 https://api.github.com/repos/pydata/xarray/issues/5073 MDEyOklzc3VlQ29tbWVudDgwNjI0Mzk5Nw== max-sixty 5635139 2021-03-24T23:15:55Z 2021-03-24T23:15:55Z MEMBER

Yes that sounds right, thanks for spotting @fmaussion . (I am hazy on the differences but I think it's a DeprecationWarning since we're removing it rather than changing its behavior)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   `lock` kwarg needs a deprecation cycle? 840258082

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