home / github

Menu
  • Search all tables
  • GraphQL API

issues

Table actions
  • GraphQL API for issues

4 rows where user = 11411331 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

type 2

  • issue 3
  • pull 1

state 2

  • closed 3
  • open 1

repo 1

  • xarray 4
id node_id number title user state locked assignee milestone comments created_at updated_at ▲ closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
1207399616 PR_kwDOAMm_X842YT9J 6501 HTML repr fix for Furo Sphinx theme kmpaul 11411331 closed 0     4 2022-04-18T20:03:01Z 2022-04-18T21:05:43Z 2022-04-18T20:53:43Z CONTRIBUTOR   0 pydata/xarray/pulls/6501
  • [x] Closes #6500
  • [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/6501/reactions",
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
    xarray 13221727 pull
1207369905 I_kwDOAMm_X85H9wCx 6500 HTML repr dark/light themes in Sphinx Furo kmpaul 11411331 closed 0     1 2022-04-18T19:26:47Z 2022-04-18T20:53:42Z 2022-04-18T20:53:42Z CONTRIBUTOR      

What is your issue?

The Xarray HTML repr assumes that light vs dark theming is stored in the html element's theme attribute (i.e., <html theme="dark"> or <html theme="light">).

However, the Sphinx Furo theme assumes that light vs dark theming is stored in the body element's data-theme attribute. As a result, if you use the Sphinx Furo theme for documentation and use Xarray HTML reprs, the Xarray HTML reprs do not display properly.

In truth, it seems that this comes down to the light vs dark theming not being standardized, which presents a problem of how to support multiple (possibly innumerable) different ways of specifying light or dark themes. That said, the Sphinx Furo theme has growing popularity, and I wonder if it could be supported as a special case (as is vscode dark themes).

To do this, one would need only modify one line of xarray/static/css/style.css:

https://github.com/pydata/xarray/blob/0db3440626721f8cdaf2f3e677d165061e870e26/xarray/static/css/style.css#L16-L17

to:

css html[theme=dark], body[data-theme=dark], body.vscode-dark {

If this is something that the Xarray community would support, I'm happy to put together a PR to do this.

{
    "url": "https://api.github.com/repos/pydata/xarray/issues/6500/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  completed xarray 13221727 issue
692106936 MDU6SXNzdWU2OTIxMDY5MzY= 4404 Documentation on tuple-type data in DataArrays kmpaul 11411331 open 0     2 2020-09-03T16:18:04Z 2020-12-07T19:07:01Z   CONTRIBUTOR      

The Problem:

When you try to construct an xarray.DataArray with tuple-type data, it will fail with the following error:

```python

xr.DataArray((7,9,3), coords=[[1,2,3]], dims=['i'])


ValueError Traceback (most recent call last) <ipython-input-17-11434cd9277e> in <module> ----> 1 xr.DataArray((7,9,3), coords=[[1,2,3]], dims=['i'])

~/Software/miniconda3/envs/pangeo/lib/python3.8/site-packages/xarray/core/dataarray.py in init(self, data, coords, dims, name, attrs, indexes, fastpath) 341 data = _check_data_shape(data, coords, dims) 342 data = as_compatible_data(data) --> 343 coords, dims = _infer_coords_and_dims(data.shape, coords, dims) 344 variable = Variable(dims, data, attrs, fastpath=True) 345 indexes = dict(

~/Software/miniconda3/envs/pangeo/lib/python3.8/site-packages/xarray/core/dataarray.py in _infer_coords_and_dims(shape, coords, dims) 92 and len(coords) != len(shape) 93 ): ---> 94 raise ValueError( 95 "coords is not dict-like, but it has %s items, " 96 "which does not match the %s dimensions of the "

ValueError: coords is not dict-like, but it has 1 items, which does not match the 0 dimensions of the data ```

This error message is not helpful, nor does it direct the user to the solution to their problem (which is to just convert the tuple to a list). This is the first part of the problem.

If the user were to learn that the reason this happened was because tuple-type data is handled specially in xarray.core.variable.as_compatible_data and returned as a 0D NumPy array, they would still be confused because the documentation states:

The DataArray constructor takes:

  • data: a multi-dimensional array of values (e.g., a numpy ndarray, Series, DataFrame or pandas.Panel)

suggesting that a list might not even be a valid type for data. So, upon further investigation, one finds that the xarray.DataArray.__init__ docstring says:

text Parameters ---------- data : array_like Values for this array. Must be an ``numpy.ndarray``, ndarray like, or castable to an ``ndarray``. If a self-described xarray or pandas object, attempts are made to use this array's metadata to fill in other unspecified arguments. A view of the array's data is used instead of a copy if possible.

which states that data must be castable to an ndarray. There are many ways of doing this, but a quick check shows that numpy.asarray((1,2,3)) and numpy.array((1,2,3)) both behave as you would expect. Thus, this confusion is the second part of the problem.

Acceptable Solutions:

  1. I am not sure why tuple-type data are treated differently with xarray. I'd like to know why because I think the easiest solution to this problem would be to remove that special treatment from xarray.core.variable.as_compatible_data. But I am sure this special treatment was written for a good reason, so I won't suggest that solution unless other developers genuinely believe that this feature can be removed.

  2. Assuming special treatment of tuple-type data is desirable, then I would propose that the documentation be improved to indicate to users what to expect. I think the documentation lacks an explanation of the tuple-type special treatment (and, perhaps, other special treatments?) and the docstrings need to be made consistent with the documentation.

{
    "url": "https://api.github.com/repos/pydata/xarray/issues/4404/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
    xarray 13221727 issue
308200446 MDU6SXNzdWUzMDgyMDA0NDY= 2013 Is it possible to disable datetime64 encoding? kmpaul 11411331 closed 0     2 2018-03-23T22:51:29Z 2018-03-23T22:56:21Z 2018-03-23T22:56:21Z CONTRIBUTOR      

I'm wondering if it is possible to disable Xarray's datetime encoding (i.e., storing it as a datetime64)? Since Xarray does not (currently) deal with units of other kinds of data, I would assume that it is possible to ignore the time units and read it (from NetCDF, for example) in its "original" form? Am I correct? If so, how to "disable datetime encoding"?

{
    "url": "https://api.github.com/repos/pydata/xarray/issues/2013/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  completed xarray 13221727 issue

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options:

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);
Powered by Datasette · Queries took 621.993ms · About: xarray-datasette