issue_comments

Table actions

10 rows where author_association = "MEMBER" and issue = 128903340 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 3

issue 1

  • DataArray creation prone to errors when data shares dimension shapes · 10 ✖

author_association 1

  • MEMBER · 10 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
244229155 https://github.com/pydata/xarray/issues/727#issuecomment-244229155 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDI0NDIyOTE1NQ== shoyer 1217238 2016-09-01T22:14:31Z 2016-09-01T22:14:31Z MEMBER

@choldgraf no worries!

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340
244228425 https://github.com/pydata/xarray/issues/727#issuecomment-244228425 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDI0NDIyODQyNQ== choldgraf 1839645 2016-09-01T22:10:56Z 2016-09-01T22:10:56Z MEMBER

whoops - that's what I get for not putting this on my to-do list...totally forgot about this issue. My bad, but thanks for fixing!

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340
175758184 https://github.com/pydata/xarray/issues/727#issuecomment-175758184 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDE3NTc1ODE4NA== choldgraf 1839645 2016-01-27T17:31:12Z 2016-01-27T17:31:12Z MEMBER

Cool - I'll make a PR in the next week or two...I know this isn't a big change but have a few deadlines in the coming days.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340
175756338 https://github.com/pydata/xarray/issues/727#issuecomment-175756338 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDE3NTc1NjMzOA== shoyer 1217238 2016-01-27T17:26:45Z 2016-01-27T17:26:45Z MEMBER

@choldgraf Yes, that looks right to me -- this code path in particular should trigger a DeprecationWarning:

# try to infer dimensions from coords if utils.is_dict_like(coords): dims = list(coords.keys())

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340
175742179 https://github.com/pydata/xarray/issues/727#issuecomment-175742179 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDE3NTc0MjE3OQ== choldgraf 1839645 2016-01-27T16:56:51Z 2016-01-27T16:56:51Z MEMBER

So it looks like the relevant code is somewhere around here, no? Is "auto-coords" done in many other places in the codebase?

And as far as future behavior, do you imagine just changing the utils.is_dict_like bits so that instead of doing magical stuff under the hood, they just throw an error from now on?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340
175417379 https://github.com/pydata/xarray/issues/727#issuecomment-175417379 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDE3NTQxNzM3OQ== choldgraf 1839645 2016-01-27T05:53:02Z 2016-01-27T05:53:02Z MEMBER

Lemme take a look at the code tomorrow. I'm pretty new to xarray but I've been meaning to learn it a bit more :-) On Jan 26, 2016 9:51 PM, "Stephan Hoyer" notifications@github.com wrote:

Any interest in putting together a PR? :)

On Tue, Jan 26, 2016 at 9:46 PM, Chris Holdgraf notifications@github.com wrote:

That sounds like a fair plan to me - throwing errors etc definitely complicates things more than just deprecating the option :)

On Tue, Jan 26, 2016 at 8:58 PM, Joe Hamman notifications@github.com wrote:

So I would support deprecating supplying dict-like coordinates without explicitly provided dims. It's more magic than we really need. This line is in the relevant code path.

I've also run into this and I'm [image: :+1:] on this solution.

— Reply to this email directly or view it on GitHub https://github.com/pydata/xarray/issues/727#issuecomment-175399404.

— Reply to this email directly or view it on GitHub https://github.com/pydata/xarray/issues/727#issuecomment-175414737.

— Reply to this email directly or view it on GitHub https://github.com/pydata/xarray/issues/727#issuecomment-175415408.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340
175415408 https://github.com/pydata/xarray/issues/727#issuecomment-175415408 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDE3NTQxNTQwOA== shoyer 1217238 2016-01-27T05:51:06Z 2016-01-27T05:51:06Z MEMBER

Any interest in putting together a PR? :)

On Tue, Jan 26, 2016 at 9:46 PM, Chris Holdgraf notifications@github.com wrote:

That sounds like a fair plan to me - throwing errors etc definitely complicates things more than just deprecating the option :)

On Tue, Jan 26, 2016 at 8:58 PM, Joe Hamman notifications@github.com wrote:

So I would support deprecating supplying dict-like coordinates without explicitly provided dims. It's more magic than we really need. This line is in the relevant code path.

I've also run into this and I'm [image: :+1:] on this solution.

— Reply to this email directly or view it on GitHub https://github.com/pydata/xarray/issues/727#issuecomment-175399404.

— Reply to this email directly or view it on GitHub https://github.com/pydata/xarray/issues/727#issuecomment-175414737.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340
175414737 https://github.com/pydata/xarray/issues/727#issuecomment-175414737 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDE3NTQxNDczNw== choldgraf 1839645 2016-01-27T05:46:36Z 2016-01-27T05:46:36Z MEMBER

That sounds like a fair plan to me - throwing errors etc definitely complicates things more than just deprecating the option :)

On Tue, Jan 26, 2016 at 8:58 PM, Joe Hamman notifications@github.com wrote:

So I would support deprecating supplying dict-like coordinates without explicitly provided dims. It's more magic than we really need. This line is in the relevant code path.

I've also run into this and I'm [image: :+1:] on this solution.

— Reply to this email directly or view it on GitHub https://github.com/pydata/xarray/issues/727#issuecomment-175399404.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340
175390102 https://github.com/pydata/xarray/issues/727#issuecomment-175390102 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDE3NTM5MDEwMg== shoyer 1217238 2016-01-27T04:38:44Z 2016-01-27T05:13:44Z MEMBER

I agree, this can be ambiguous. It makes sense for ordered mappings, but not for normal dicts. And unfortunately there is no Pythonic way to tell whether a mapping is ordered or not.

I originally included it because I wanted to make sure operations like xr.DataArray(2 * x.data, x.coords) preserve all original dimensions in order. But, given that we define DataArray.coords.dims and use that to fill in an empty dims argument, we don't really need this anymore. If someone really likes supplying coordinates as an OrderedDict, it's simple enough for them to write coords.items() instead.

So I would support deprecating supplying dict-like coordinates without explicitly provided dims. It's more magic than we really need. This line is in the relevant code path.

I don't want to simply error when coordinates have ambiguous lengths compared to the size of the data, because adding errors in special cases makes things harder to predict.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340
175399404 https://github.com/pydata/xarray/issues/727#issuecomment-175399404 https://api.github.com/repos/pydata/xarray/issues/727 MDEyOklzc3VlQ29tbWVudDE3NTM5OTQwNA== jhamman 2443309 2016-01-27T04:58:35Z 2016-01-27T04:58:35Z MEMBER

So I would support deprecating supplying dict-like coordinates without explicitly provided dims. It's more magic than we really need. This line is in the relevant code path.

I've also run into this and I'm :+1: on this solution. 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   DataArray creation prone to errors when data shares dimension shapes 128903340

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