home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

5 rows where author_association = "CONTRIBUTOR" and user = 280924 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)

issue 3

  • Support non-string dimension/variable names 2
  • OrderedDict --> dict, some python3.5 cleanup too 2
  • can the callables of apply_ufunc + dask get a typed/labeled array 1

user 1

  • ttung · 5 ✖

author_association 1

  • CONTRIBUTOR · 5 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
545301953 https://github.com/pydata/xarray/pull/3389#issuecomment-545301953 https://api.github.com/repos/pydata/xarray/issues/3389 MDEyOklzc3VlQ29tbWVudDU0NTMwMTk1Mw== ttung 280924 2019-10-23T07:07:10Z 2019-10-23T07:07:10Z CONTRIBUTOR

No idea if there are any other ones; you're probably right.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  OrderedDict --> dict, some python3.5 cleanup too 505409694
544606329 https://github.com/pydata/xarray/pull/3389#issuecomment-544606329 https://api.github.com/repos/pydata/xarray/issues/3389 MDEyOklzc3VlQ29tbWVudDU0NDYwNjMyOQ== ttung 280924 2019-10-21T16:52:32Z 2019-10-21T16:52:32Z CONTRIBUTOR

FYI, python 3.6 does not guarantee that dicts are ordered. CPython 3.6 happens to have that implementation but pypy, for instance, is not required to follow that. Python 3.7, however, mandates that dicts are ordered.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  OrderedDict --> dict, some python3.5 cleanup too 505409694
472139607 https://github.com/pydata/xarray/issues/2807#issuecomment-472139607 https://api.github.com/repos/pydata/xarray/issues/2807 MDEyOklzc3VlQ29tbWVudDQ3MjEzOTYwNw== ttung 280924 2019-03-12T19:04:59Z 2019-03-12T19:04:59Z CONTRIBUTOR

I understand that there might be some challenges with returning xarray objects, but it seems like taking xarray objects should be very straightforward. Anything problematic about that?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  can the callables of apply_ufunc + dask get a typed/labeled array 420139027
410008899 https://github.com/pydata/xarray/issues/2292#issuecomment-410008899 https://api.github.com/repos/pydata/xarray/issues/2292 MDEyOklzc3VlQ29tbWVudDQxMDAwODg5OQ== ttung 280924 2018-08-02T17:38:52Z 2018-08-02T17:38:52Z CONTRIBUTOR

The problem with generic scalar types is that it wouldn't work after serialization and deserialization (which would presumably go to strings). My suggestion has the advantage of being able to create a __eq__ method in the base class that would match both the object itself or its string equivalent, so that one could use the scalar type even after ser/deser. I disagree that base classes aren't very pythonic.

However, I think (1)/(2) are both reasonable solution (in fact, they seem to be identical except for when you call str). It has its warts, as even a mutable sequence would pass muster. :)

If that's the direction you'd like to see the project go towards, I'd be happy to take a stab at it.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Support non-string dimension/variable names 341643235
409822333 https://github.com/pydata/xarray/issues/2292#issuecomment-409822333 https://api.github.com/repos/pydata/xarray/issues/2292 MDEyOklzc3VlQ29tbWVudDQwOTgyMjMzMw== ttung 280924 2018-08-02T06:38:32Z 2018-08-02T06:38:32Z CONTRIBUTOR

We're using xarray in a project that is encouraging use of python typing, and we too would like to use enums as data dimension names. How do you feel about using a base class that data dimension classes need to subclass?

Here's a really simple proof-of-concept (though not very thorough, as it would certainly fail serialization): https://github.com/ttung/xarray/commit/8e623ebebc8f5c1e5615e6d07a82451c0dbe763d

``` In [1]: import xarray as xr

In [2]: import numpy as np

In [5]: from enum import Enum

In [6]: class A(xr.core.dataarray.DimensionBase, Enum): ...: X = "abc" ...: Y = "def" ...: Z = "ghi" ...:

In [7]: a = xr.DataArray(np.random.randint(0, 255, size=(4, 3, 5)), dims=[A.X, A.Y, A.Z])

In [8]: a[A.X] Out[8]: <xarray.DataArray \<A.X: 'abc'> (A.X: 4)> array([0, 1, 2, 3]) Dimensions without coordinates: A.X

In [9]: a.max(A.X) Out[9]: <xarray.DataArray (A.Y: 3, A.Z: 5)> array([[254, 226, 181, 191, 233], [139, 195, 212, 167, 169], [191, 241, 199, 174, 208]]) Dimensions without coordinates: A.Y, A.Z

In [10]: ```

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Support non-string dimension/variable names 341643235

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]);
Powered by Datasette · Queries took 14.414ms · About: xarray-datasette