issues

Table actions

3 rows where repo = 13221727, type = "pull" and user = 13662783 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)

state 2

type 1

  • pull · 3 ✖

repo 1

  • xarray · 3 ✖
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
445745470 MDExOlB1bGxSZXF1ZXN0MjgwMTIwNzIz 2972 ENH: Preserve monotonic descending index order when merging Huite 13662783 open 0     4 2019-05-18T19:12:11Z 2022-06-09T14:50:17Z   CONTRIBUTOR   0 pydata/xarray/pulls/2972

  • Addresses GH2947

  • When indexes were joined in a dataset merge, they would always get sorted in ascending order. This is awkward for geospatial grids, which are nearly always descending in the "y" coordinate.

  • This also caused an inconsistency: when a merge is called on datasets with identical descending indexes, the resulting index is descending. When a merge is called with non-identical descending indexes, the resulting index is ascending.

  • When indexes are mixed ascending and descending, or non-monotonic, the resulting index is still sorted in ascending order.

  • [x] Closes #2947
  • [x] Tests added
  • [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

Comments

I was doing some work and I kept running into the issue described at #2947, so I had a try at a fix. It was somewhat of a hassle to understand the issue because I kept running into seeming inconsistencies. This is caused by the fact that the joiner doesn't sort with a single index:

python def _get_joiner(join): if join == 'outer': return functools.partial(functools.reduce, operator.or_) That makes sense, since I'm guessing pandas.Index.union isn't get called at all. (I still find the workings of functools a little hard to infer.)

I also noticed that an outer join gets called with e.g. an .isel operation, even though there's only one index (so there's not really anything to join). However, skipping the join completely in that case makes several tests fail since dimension labels end up missing (I guess the joiner call takes care of it).

It's just checking for the specific case now, but it feels like an very specific issue anyway...

The merge behavior is slightly different now, which is reflected in the updated test outcomes in test_dataset.py. These tests were turning monotonic decreasing indexes into an increasing index; now the decreasing order is maintained.

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/2972/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull
601364609 MDExOlB1bGxSZXF1ZXN0NDA0NjM0Mjk0 3979 full_like: error on non-scalar fill_value Huite 13662783 closed 0     2 2020-04-16T19:18:50Z 2020-04-24T07:15:49Z 2020-04-24T07:15:44Z CONTRIBUTOR   0 pydata/xarray/pulls/3979
  • [x] Closes #3977
  • [x] Tests added
  • [x] Passes isort -rc . && black . && mypy . && flake8
  • [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

@dcherian's suggestion in #3977 seemed straightforward enough for me to have a try.

Two thoughts: * does the np.isscalar check belong in the outer function, or the inner? The inner function is only called by the outer one. * Bugfix or arguably a breaking change?

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/3979/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull
510505541 MDExOlB1bGxSZXF1ZXN0MzMwODY3ODI0 3428 Address multiplication DeprecationWarning in rasterio backend Huite 13662783 closed 0     2 2019-10-22T08:32:25Z 2019-10-22T18:45:32Z 2019-10-22T18:45:24Z CONTRIBUTOR   0 pydata/xarray/pulls/3428

Very minor change to address this DeprecationWarning:

xarray\backends\rasterio_.py:260: DeprecationWarning: Right multiplication will be prohibited in version 3.0 x, _ = (np.arange(nx) + 0.5, np.zeros(nx) + 0.5) * riods.transform

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

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