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 278713328,MDU6SXNzdWUyNzg3MTMzMjg=,1756,Deprecate inplace methods,1217238,closed,0,,2856429,6,2017-12-02T20:09:00Z,2019-03-25T19:19:10Z,2018-11-03T21:24:13Z,MEMBER,,,,"The following methods have an `inplace` argument: `DataArray.reset_coords` `DataArray.set_index` `DataArray.reset_index` `DataArray.reorder_levels` `Dataset.set_coords` `Dataset.reset_coords` `Dataset.rename` `Dataset.swap_dims` `Dataset.set_index` `Dataset.reset_index` `Dataset.reorder_levels` `Dataset.update` `Dataset.merge` As proposed in https://github.com/pydata/xarray/issues/1755#issuecomment-348682403, let's deprecate all of these at the next major release (v0.11). They add unnecessary complexity to methods and promote confusing about xarray's data model. Practically, we would change all of the default values to `inplace=None` and issue either a `DeprecationWarning` or `FutureWarning` (see [PEP 565](https://www.python.org/dev/peps/pep-0565/#additional-use-case-for-futurewarning) for more details on that choice).","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1756/reactions"", ""total_count"": 4, ""+1"": 4, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 207477701,MDU6SXNzdWUyMDc0Nzc3MDE=,1267,"""in"" operator does not work as expected on DataArray dimensions",5629061,closed,0,,2856429,2,2017-02-14T10:35:41Z,2018-10-28T17:56:17Z,2018-10-28T17:56:17Z,NONE,,,,"As an example I have a DataArray called ""my_dataarray"" that looks something like this: ``` array([1, 2, 3]) Coordinates: * Type (Type) object 'Type 1' 'Type 2' 'Type 3' ``` 'Type' is a dimension on my DataArray. Note that 'Type' is also a DataArray that looks like this: ``` OrderedDict([('Type', array(['Type 1', 'Type 2', 'Type 3'], dtype='object'))]) ``` Let's say I run: ``` 'Type 1' in my_dataarray.Type ``` The result is False, even though 'Type 1' is in the ""Type"" dimension. To get the result I was expecting I need to run: ``` 'Type 1' in my_dataarray.Type.values ``` Stepping through the code, the problematic line is here: https://github.com/pydata/xarray/blob/20ec32430fac63a8976699d9528b5fdc1cd4125d/xarray/core/dataarray.py#L487 The test used for `__contains__(self, key)` on the Type dimension is whether the key is in the `_coords` of Type. This is probably the right thing to do when the DataArray is used for storing data, but probably not what we want if the DataArray is being used as a dimension - it should instead check if 'Type 1' is in the *values* of Type? ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1267/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 160505403,MDU6SXNzdWUxNjA1MDU0MDM=,884,Iterating over a Dataset iterates only over its data_vars,5635139,closed,0,,2856429,11,2016-06-15T19:35:50Z,2018-10-25T15:26:59Z,2018-10-25T15:26:59Z,MEMBER,,,,"This has been a small-but-persistent issue for me for a while. I suspect that my perspective might be dependent on my current outlook, but socializing it here to test if it's secular... Currently `Dataset.keys()` returns both variables and coordinates (but not its `attrs` keys): ``` python In [5]: ds=xr.Dataset({'a': (('x', 'y'), np.random.rand(10,2))}) In [12]: list(ds.keys()) Out[12]: ['a', 'x', 'y'] ``` Is this conceptually correct? I would posit that a Dataset is a mapping of _keys to variables_, and the coordinates contain values that _label_ that data. **So should `Dataset.keys()` instead return just the keys of the Variables?** We're often passing around a dataset as a `Mapping` of keys to values - but then when we run a function across each of the keys, we get something run on both the Variables' keys, _and_ the Coordinate / label's keys. In Pandas, `DataFrame.keys()` returns just the columns, so that conforms to what we need. While I think the xarray design is in general much better in these areas, this is one area that pandas seems to get correct - and because of the inconsistency between pandas & xarray, we're having to coerce our objects to pandas `DataFrame`s before passing them off to functions that pull out their keys (this is also why we can't just look at `ds.data_vars.keys()` - because it breaks that duck-typing). Does that make sense? ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/884/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 327905732,MDExOlB1bGxSZXF1ZXN0MTkxNTg1ODU4,2204,update minimum versions and associated code cleanup,2443309,closed,0,,2856429,6,2018-05-30T21:27:14Z,2018-07-08T00:55:36Z,2018-07-08T00:55:32Z,MEMBER,,0,pydata/xarray/pulls/2204," - [x] closes #2200, closes #1829, closes #2203 - [x] Tests passed (for all non-documentation changes) - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later) This updates the following minimum versions: - numpy: 1.11 (Mar 27, 2016) --> 1.12 (Jan 15, 2017) - pandas: 0.18 (Mar 11, 2016) --> 0.19 (Oct 2, 2016) - dask: 0.9 (May 10, 2016) --> 0.16 and drops our tests for python 3.4. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/2204/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 288465429,MDU6SXNzdWUyODg0NjU0Mjk=,1829,Drop support for Python 3.4,2443309,closed,0,,2856429,13,2018-01-15T02:38:19Z,2018-07-08T00:55:32Z,2018-07-08T00:55:32Z,MEMBER,,,,"Python 3.7-final is due out in June ([PEP 537](https://www.python.org/dev/peps/pep-0537/)). When do we want to deprecate 3.4 and when should we drop support all together. @maxim-lian brought this up in a PR he's working on: https://github.com/pydata/xarray/pull/1828#issuecomment-357562144. For reference, we dropped Python 3.3 in #1175 (12/20/2016).","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/1829/reactions"", ""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue