issue_comments

Table actions

4 rows where issue = 438389323 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 2

author_association 2

issue 1

  • Dask outputs warning: "The da.atop function has moved to da.blockwise" · 4 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
510939525 https://github.com/pydata/xarray/issues/2928#issuecomment-510939525 https://api.github.com/repos/pydata/xarray/issues/2928 MDEyOklzc3VlQ29tbWVudDUxMDkzOTUyNQ== lumbric 691772 2019-07-12T15:56:28Z 2019-07-12T15:56:28Z CONTRIBUTOR

Fixed in 714ae8661a829d.

(Sorry for the delay... I actually prepared a PR but never finished it completely even it was such a simple thing.)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Dask outputs warning: "The da.atop function has moved to da.blockwise" 438389323
487782633 https://github.com/pydata/xarray/issues/2928#issuecomment-487782633 https://api.github.com/repos/pydata/xarray/issues/2928 MDEyOklzc3VlQ29tbWVudDQ4Nzc4MjYzMw== shoyer 1217238 2019-04-29T23:52:25Z 2019-04-29T23:52:25Z MEMBER

The thing I don't really understand and why I wanted to ask first: is there a clear paradigm about compatibility in the pydata universe? Despite its 0.x version number, I guess xarray tries to stay backward compatible regarding its public interface, right? When are the versions of dependencies increase? Simply motivated by need of new features in one of the dependent libraries?

The usual rule of thumb is to keep things working for at least one "major" release with a deprecation warning, so that somebody who continuously runs their code has time to notice before things break.

The exact appropriate time to wait is project dependent. In xarray's case, we've usually been waiting 6-12 months before making breaking changes. NumPy might wait 2-3 years.

There isn't a strict rule for bumping required dependency versions, but again it's motivated by a desire to give users some flexibility so as not to require them to upgrade everything at once.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Dask outputs warning: "The da.atop function has moved to da.blockwise" 438389323
487759590 https://github.com/pydata/xarray/issues/2928#issuecomment-487759590 https://api.github.com/repos/pydata/xarray/issues/2928 MDEyOklzc3VlQ29tbWVudDQ4Nzc1OTU5MA== lumbric 691772 2019-04-29T22:00:58Z 2019-04-29T22:00:58Z CONTRIBUTOR

Any interest in putting together a PR?

Yes, can do so. When writing the report, I actually thought maybe preparing a PR is easier to write and to read than the ticket... :) In this case it really shouldn't be a big deal fixing it.

Maybe a bit off-topic: The thing I don't really understand and why I wanted to ask first: is there a clear paradigm about compatibility in the pydata universe? Despite its 0.x version number, I guess xarray tries to stay backward compatible regarding its public interface, right? When are the versions of dependencies increase? Simply motivated by need of new features in one of the dependent libraries?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Dask outputs warning: "The da.atop function has moved to da.blockwise" 438389323
487750028 https://github.com/pydata/xarray/issues/2928#issuecomment-487750028 https://api.github.com/repos/pydata/xarray/issues/2928 MDEyOklzc3VlQ29tbWVudDQ4Nzc1MDAyOA== shoyer 1217238 2019-04-29T21:26:03Z 2019-04-29T21:26:03Z MEMBER

Not sure, can xarray break compatibility with dask <1.1.0 with some future version? Otherwise I guess there needs to be some legacy code in xarray which calls the right function.

Thanks for the report.

Yes, we can definitely do this in the future, but for now, I think we should try to be backwards compatible.

Using something like the following instead xarray should solve this: python try: blockwise = dask.array.blockwise # new name in dask 1.1 except AttributeError: blockwise = dask.array.atop

Any interest in putting together a PR?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Dask outputs warning: "The da.atop function has moved to da.blockwise" 438389323

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