pull_requests: 548186360
This data as json
| id | node_id | number | state | locked | title | user | body | created_at | updated_at | closed_at | merged_at | merge_commit_sha | assignee | milestone | draft | head | base | author_association | auto_merge | repo | url | merged_by |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 548186360 | MDExOlB1bGxSZXF1ZXN0NTQ4MTg2MzYw | 4759 | closed | 0 | coords: retain str dtype | 10194086 | <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Closes #2658, closes #4543 - [x] Tests added - [x] Passes `isort . && black . && mypy . && flake8` - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` `pd.Index("a")` has dtype `object`. Therefore string coords change their dtype on certain operations - e.g. `align`, `__setitem__` (& `assign`), `IndexVariable.concat`. This can be avoided by using the coords instead of the index in some cases but in two instances it was unavoidable to cast a `pd.Index` back to a `np.array`. I probably did not catch all of these conversions. What I am not sure: does this somehow contradict the index refactor? | 2021-01-04T11:17:53Z | 2021-01-13T17:18:28Z | 2021-01-13T17:09:06Z | 2021-01-13T17:09:05Z | fb67358ceb0c386560e6a6991dd937292ba54d46 | 0 | 4f23a3c1d18286adcd6677e44a030b1547cd9435 | f52a95cbe694336fe47bc5a42c713bee8ad74d64 | MEMBER | 13221727 | https://github.com/pydata/xarray/pull/4759 |
Links from other tables
- 0 rows from pull_requests_id in labels_pull_requests