pull_requests
372 rows where user = 5635139
This data as json, CSV (advanced)
Suggested facets: state, draft, auto_merge, created_at (date), updated_at (date), closed_at (date), merged_at (date)
| 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 49874287 | MDExOlB1bGxSZXF1ZXN0NDk4NzQyODc= | 646 | closed | 0 | Selection works with PeriodIndex-like indexes | max-sixty 5635139 | Resolves the most pressing issue in #645 | 2015-11-05T20:13:44Z | 2015-11-18T01:03:06Z | 2015-11-06T05:44:01Z | 2015-11-06T05:44:01Z | bc97ee0fbdb421f5233aa8ebabe885d5db3b516c | 0 | e860326a32dd47609457c37d3d4ddfa70c3b3e9b | 52d38a7796eb1003fd3cc18660063c9c7a4e5938 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/646 | ||||
| 50343808 | MDExOlB1bGxSZXF1ZXN0NTAzNDM4MDg= | 654 | closed | 0 | docs consistent with Dataset constructor taking variables | max-sixty 5635139 | I think these should be `variables` rather than `data_vars` / `data`? | 2015-11-11T03:19:50Z | 2015-12-03T21:48:09Z | 2015-12-03T19:00:47Z | 2015-12-03T19:00:47Z | d30d4591e44e678044e9a56759261e8f218e6f07 | 0.7.0 1368762 | 0 | 7111eb4688fce0430192c105b5ff54b1fa1d1c78 | 78df2ed528b2247313b28ae5b61faa801d426a50 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/654 | |||
| 52738754 | MDExOlB1bGxSZXF1ZXN0NTI3Mzg3NTQ= | 671 | closed | 0 | Align pandas objects with named indexes | max-sixty 5635139 | closes https://github.com/xray/xray/issues/664. What's new & docs forthcoming | 2015-12-05T00:20:41Z | 2015-12-10T22:38:33Z | 2015-12-08T07:23:41Z | 2015-12-08T07:23:41Z | b455d67832bf130feef937aceae4d74e37919fb7 | 0 | 9a88cb965ab92dac99feb8aac0cb07b4fd4643c7 | b7b8faee9156901e692f1923d665a802574db833 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/671 | ||||
| 53312830 | MDExOlB1bGxSZXF1ZXN0NTMzMTI4MzA= | 675 | closed | 0 | Doc formatting fix | max-sixty 5635139 | No margin of error in these...  | 2015-12-10T20:34:51Z | 2015-12-10T22:40:36Z | 2015-12-10T21:41:23Z | 2015-12-10T21:41:23Z | 8082c775f496a26cf1e699dd3fe5a4a5f7acdb55 | 0 | 64613283220e48fc50c8743ed17b5ce9bdf5be09 | 1a3469b5017867eafcc37223c985c49fe5d47496 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/675 | ||||
| 53332806 | MDExOlB1bGxSZXF1ZXN0NTMzMzI4MDY= | 677 | closed | 0 | Dataset constructor can take pandas objects | max-sixty 5635139 | Closes a 'first-step' of https://github.com/xray/xray/issues/676. Works only for simple, non-MultiIndexed, pandas objects. | 2015-12-10T23:22:32Z | 2016-01-02T07:44:26Z | 2016-01-02T07:34:50Z | 2016-01-02T07:34:50Z | 7c84936eb96e189c3e01028d80a9656d4e0baa46 | 0 | 3e567895b17f390a9a11d2a6f098206d220f8e44 | 922774d648d0058720401934640078bc0ddf7d05 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/677 | ||||
| 54902359 | MDExOlB1bGxSZXF1ZXN0NTQ5MDIzNTk= | 698 | closed | 0 | Allow empty DataFrame in Dataset construction | max-sixty 5635139 | Closes https://github.com/xray/xray/issues/697 @shoyer: am I missing something as to why the special case was there? | 2016-01-02T07:01:58Z | 2016-01-02T07:34:42Z | 2016-01-02T07:26:29Z | 2016-01-02T07:26:29Z | a05fb1a6406dd48c35907709cb92d167e6aa77e0 | 0 | d57414d6dbf74079877bc8f581a3084994e971e3 | 922774d648d0058720401934640078bc0ddf7d05 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/698 | ||||
| 58015101 | MDExOlB1bGxSZXF1ZXN0NTgwMTUxMDE= | 741 | closed | 0 | Allow empty result of numerical operations between DataArrays | max-sixty 5635139 | Resolves https://github.com/pydata/xarray/issues/739 @shoyer let me know your thoughts and I'll add what's new note | 2016-02-02T16:50:46Z | 2016-02-16T05:22:24Z | 2016-02-16T05:01:11Z | 2016-02-16T05:01:11Z | a56b47b4c3c004a809703f7492a8055e01b19a63 | 0 | 9d5872ada9af0bd9572d6ea9908c399a867c66c2 | 8d84fa864f4829cea68e22b70657c76fcacc7ef5 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/741 | ||||
| 58233318 | MDExOlB1bGxSZXF1ZXN0NTgyMzMzMTg= | 746 | closed | 0 | BUG: Don't transpose variables of one dimension | max-sixty 5635139 | Resolves https://github.com/pydata/xarray/issues/745 A bit of a 'convenient hack'. Let me know if you think there's a better way to do this | 2016-02-04T02:29:06Z | 2016-02-09T16:46:40Z | 2016-02-09T16:05:28Z | 2016-02-09T16:05:28Z | 08cc04f6c0270bbbaef2923439e6d934d3febfd2 | 0 | 0c6dcf38d126e887d609f3c4afa27da005d6cf62 | dcf2b5b8dacbaab8b131240ea3aaf2f79f100525 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/746 | ||||
| 58656450 | MDExOlB1bGxSZXF1ZXN0NTg2NTY0NTA= | 749 | closed | 0 | Retain label type in .to_dataset | max-sixty 5635139 | Not sure if this was a deliberate choice (maybe so integer indexing wasn't disrupted?). This allows objects as dataset keys / labels. Let me know your thoughts and I'll add a what's new. (I know I have a few PRs dangling - apologies - will go back and clean them up soon) | 2016-02-08T19:38:59Z | 2016-02-16T03:51:06Z | 2016-02-14T23:34:56Z | 2016-02-14T23:34:56Z | 9559e5b54248f9566a65e5af2c8d0678f78fcb3f | 0 | 7c44661ada230f29a5fecc9407e9fb29577fd57c | b5aa9c25a1d331a680edf8eb1eee61421a60f9d7 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/749 | ||||
| 59587684 | MDExOlB1bGxSZXF1ZXN0NTk1ODc2ODQ= | 764 | closed | 0 | Coerce Series to dict in Dataset constructor | max-sixty 5635139 | Resolves https://github.com/pydata/xarray/issues/740 | 2016-02-17T02:28:10Z | 2016-02-17T06:30:07Z | 2016-02-17T06:21:57Z | 2016-02-17T06:21:57Z | cac4ba40f2b9321a4a8f0c2f536dc66ff540dfb1 | 0 | e88dd544bebc09ad803859dedb78b9a9a4cf748c | 56ddfb803a249c80103689d46597018b8648d372 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/764 | ||||
| 60041526 | MDExOlB1bGxSZXF1ZXN0NjAwNDE1MjY= | 773 | closed | 0 | IDEs resolves ops | max-sixty 5635139 | resolves #771 | 2016-02-20T07:54:49Z | 2016-02-22T02:20:31Z | 2016-02-22T02:02:02Z | 2016-02-22T02:02:02Z | 84461554743dcbccf3de2cc121456c65e41381b8 | 0 | 1005a9e348f759f9e351292cf0b9f25858b093e8 | eda0d02a8c90511e26c85c5aae1e68332752bc5f | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/773 | ||||
| 66897722 | MDExOlB1bGxSZXF1ZXN0NjY4OTc3MjI= | 832 | closed | 0 | WIP for transitioning from Panel docs | max-sixty 5635139 | A start for some docs on transitioning from pandas Panel to xarray. This is some way from the final version - but putting it out there and will iterate. | 2016-04-18T18:16:41Z | 2016-08-08T17:08:23Z | 2016-08-08T17:08:23Z | 2016-08-08T17:08:23Z | 50f647339ed05dd3feba6acf099b234621469937 | 0 | 556259ccaa1a819fa43bd6ccb2e2f6826a0e7f38 | 7d7673c14bb7d6468c8671e1229b3b4bdfb82c4a | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/832 | ||||
| 70932637 | MDExOlB1bGxSZXF1ZXN0NzA5MzI2Mzc= | 852 | closed | 0 | BUG: Stringify DS attrs in dir | max-sixty 5635139 | Previously: ``` python In [21]: ds Out[21]: <xarray.Dataset> Dimensions: (abc: 3) Coordinates: * abc (abc) int64 0 1 2 Data variables: 0 (abc) float64 0.3168 0.1132 0.6664 1 (abc) float64 0.9799 0.9663 0.01084 2 (abc) float64 0.9171 0.6848 0.5028 In [22]: dir(ds) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-22-fd55ce5c03db> in <module>() ----> 1 dir(ds) /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/xarray/core/common.py in __dir__(self) 157 extra_attrs = [item for sublist in self._attr_sources 158 for item in sublist] --> 159 return sorted(set(dir(type(self)) + extra_attrs)) 160 161 TypeError: unorderable types: numpy.ndarray() > str() ``` | 2016-05-21T00:07:23Z | 2016-08-10T01:15:31Z | 2016-08-10T01:13:50Z | f3643af453b36cefc55ef5d1099d44ac50a7eedf | 0 | c2a4750c6ff7be8f31cb3cbdc458ca48662c73ce | e889b88fe4c8863cc0eea093dc4eff1542e2c786 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/852 | |||||
| 70935725 | MDExOlB1bGxSZXF1ZXN0NzA5MzU3MjU= | 854 | closed | 0 | BUG: Allow arbitrary objects to be Dataset values | max-sixty 5635139 | Closes https://github.com/pydata/xarray/issues/847 The method here might be a bit sweeping. Let me know your thoughts | 2016-05-21T01:22:16Z | 2016-08-12T06:06:19Z | 2016-08-12T06:06:19Z | 2016-08-12T06:06:18Z | 78283563900e0f7acfd9264db8cfba9117efa169 | 0 | 4475b36973221c34739c4fc4cd0413c8f09dfbad | b708f71f05cccfc4c7063ea58c25c46cfe37dd8d | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/854 | ||||
| 95989737 | MDExOlB1bGxSZXF1ZXN0OTU5ODk3Mzc= | 1145 | closed | 0 | Rolling count | max-sixty 5635139 | closes https://github.com/pydata/xarray/issues/1138 | 2016-11-30T22:44:50Z | 2017-06-26T18:43:06Z | 2017-06-26T18:43:06Z | 2017-06-26T18:43:06Z | 84ee8d765aec8a7a48a8163fe0cb3253f9ffd702 | 0 | aff15061da6b3b3b45f6ca02f2a91a685d3b9806 | 22ff955d53e253071f6e4fa849e5291d0005282a | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1145 | ||||
| 96004697 | MDExOlB1bGxSZXF1ZXN0OTYwMDQ2OTc= | 1146 | closed | 0 | Minor test fixes | max-sixty 5635139 | A couple of tests weren't actually testing anything. I may add things onto this PR if I see them | 2016-12-01T00:45:55Z | 2016-12-01T01:23:50Z | 2016-12-01T01:23:50Z | 2016-12-01T01:23:50Z | d01077ae38ca9d48560517a9ce721be2c6c580d5 | 0 | bf62e45e9c33d625febe88df96f24810eb24d21d | cc10cc5981fc9cc9bd1c572d073c27dde4e98cc4 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1146 | ||||
| 96025019 | MDExOlB1bGxSZXF1ZXN0OTYwMjUwMTk= | 1147 | closed | 0 | Pytest assert functions | max-sixty 5635139 | Is this a reasonable function to use with py.test? In place of the inheritance `.assertVariableEqual` etc. - Do we want separate functions for each class? - There's a comment `or just switch to py.test and add an appropriate hook.` - is that different to what's here? - This still needs to be completed, with additional functions for `assert _identical` and `assert_approx_equal`. - Do we want more description for the failure, above just printing the arguments? That can also be added later | 2016-12-01T04:36:56Z | 2016-12-22T19:20:08Z | 2016-12-22T19:20:08Z | 2016-12-22T19:20:08Z | 9dcfa733b307c74a561e72b945331269a5b93126 | 0 | dcf4f0501ec0429830ff1667b58f3ebe99a7ccb9 | aec3e8e8208f557864feb8f3e6a1c8c6cc200bc5 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1147 | ||||
| 97057032 | MDExOlB1bGxSZXF1ZXN0OTcwNTcwMzI= | 1157 | closed | 0 | PERF: Use len rather than size | max-sixty 5635139 | Potential mitigation for https://github.com/pandas-dev/pandas/issues/14822 | 2016-12-08T04:23:24Z | 2016-12-09T18:36:55Z | 2016-12-09T18:36:50Z | 2016-12-09T18:36:50Z | 1615a0f65c331ef5f7c6be83eccf9a1c6796fa77 | 0 | 39b3ea9ab5c06d322b735db7907f54d0e9774058 | 21b22808793cfd0905047d0384a26c13507db93b | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1157 | ||||
| 98871038 | MDExOlB1bGxSZXF1ZXN0OTg4NzEwMzg= | 1175 | closed | 0 | End support for py3.3? | max-sixty 5635139 | Even at the beginning of this year its downloads were 90% lower than 2.6: https://hynek.me/articles/python3-2016/ Impetus is that pytest no longer supports it, and some of the tests I recently wrote don't work on 3.3 | 2016-12-21T04:42:38Z | 2016-12-21T06:21:20Z | 2016-12-21T06:21:16Z | 2016-12-21T06:21:16Z | aec3e8e8208f557864feb8f3e6a1c8c6cc200bc5 | 0 | fc001c8cdae81f80c98c408896ab51f74652e362 | 34fd2b6cb94dfb824c5371c37b6eb5e70a88260f | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1175 | ||||
| 105282858 | MDExOlB1bGxSZXF1ZXN0MTA1MjgyODU4 | 1256 | closed | 0 | PERF: Override equals in IndexVariable | max-sixty 5635139 | - [x] closes #1255 - [ ] tests added / passed - [x] passes ``git diff upstream/master | flake8 --diff`` - [ ] whatsnew entry I tried adding some tests but couldn't find a good way of doing that There is a 20x speed-up though (see issues for prior): ```python In [51]: indexes = [pd.PeriodIndex(start=str((1776 + i)), freq='A', periods=300) for i in range(50)] In [53]: das = [xr.DataArray(range(300), coords=[index]) for index in indexes] In [54]: %timeit xr.concat(das) 10 loops, best of 3: 70.2 ms per loop ``` | 2017-02-08T19:06:09Z | 2017-02-10T22:56:26Z | 2017-02-09T15:31:15Z | 2017-02-09T15:31:15Z | ed71fbb248e758eb73d912462890f7672574b81e | 0 | ff2545fe927ee39d9ce4d9a884b0ac045fa7a177 | d49014d0357d08289cf99aeb54bcefe48ed6e7a0 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1256 | ||||
| 151232906 | MDExOlB1bGxSZXF1ZXN0MTUxMjMyOTA2 | 1696 | closed | 0 | ffill & bfill methods | max-sixty 5635139 | - [x] Closes #1651 - [x] Tests added / passed - [ ] Passes ``git diff upstream/master **/*py | flake8 --diff`` - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API No docs / docstrings. No backfill. But otherwise is this a reasonable layout? Do we prefer `fillna` with options (back / forward / replacement), or `ffill`, `bfill`, `fillna`? | 2017-11-07T21:32:19Z | 2017-11-12T00:14:33Z | 2017-11-12T00:14:29Z | 8c8003fcfcc8c2d0f27712fd795817d403a9012b | 0 | 3c9359cb17820be76f25d09c9a987236a7a7d40f | fb6e13ec15e85bbeceedbcd754e063f6e5696bf7 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1696 | |||||
| 162797751 | MDExOlB1bGxSZXF1ZXN0MTYyNzk3NzUx | 1825 | closed | 0 | Testing deprecations | max-sixty 5635139 | Re comment here: https://github.com/pydata/xarray/pull/1640#discussion_r158384496 The `TestCase` functions I think we should deprecate `_importorskip` I'm less sure about - there are some reasons to keep them if we need flexibility in the future (and it doesn't matter much) | 2018-01-13T21:18:01Z | 2018-01-14T20:54:13Z | 2018-01-14T20:54:07Z | 9092b5a21c5e708fac209a4c92ff2751acf12d5c | 0 | 252f7a694218274ca76f2a9959738d70e71fb62d | 502a988ad5b87b9f3aeec3033bf55c71272e1053 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1825 | |||||
| 162800541 | MDExOlB1bGxSZXF1ZXN0MTYyODAwNTQx | 1826 | closed | 0 | Align DataArrays based on coords in Dataset constructor | max-sixty 5635139 | - [x] Closes #674 - [x] Tests added (for all bug fixes or enhancements) - [x] Tests passed (for all non-documentation changes) - [x] Passes ``git diff upstream/master **/*py | flake8 --diff`` (remove if you did not edit any Python files) - [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) | 2018-01-13T22:35:21Z | 2018-05-31T00:53:28Z | 2018-05-31T00:22:59Z | 2018-05-31T00:22:59Z | 7036eb5b629f2112da9aa13538aecb07f0f83f5a | 0 | 1fa7d87bd6ca13b095acddced6a5662f327ac1f0 | 847050026d45e2817960a37564bd8e909ecbdb05 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1826 | ||||
| 162809807 | MDExOlB1bGxSZXF1ZXN0MTYyODA5ODA3 | 1828 | closed | 0 | pytest-ification | max-sixty 5635139 | So far, only the changes that `unittest2pytest` could fix. Need to work out how to sort through the exisiting xarray ones EDIT: ready to merge (and keen to get this in before there are divergences from other branches) | 2018-01-14T04:33:17Z | 2018-01-15T22:25:33Z | 2018-01-15T22:25:30Z | 2018-01-15T22:25:30Z | f3deb2f2495220af819021b199a5305b0d62ef36 | 0 | ec9d88ca045cc690e8188a7062799c64dd2539c5 | 0d69bf9dbf281f0f0f48ac2fadda61a82533aac3 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1828 | ||||
| 170078190 | MDExOlB1bGxSZXF1ZXN0MTcwMDc4MTkw | 1924 | closed | 0 | isort | max-sixty 5635139 | Not sure if we want this? Probably too strict to enforce on every commit, more permissible to do a one-time update, assuming it doesn't cause merge conflicts. You can get the same result by running `isort -y` | 2018-02-20T00:32:51Z | 2018-02-27T19:33:38Z | 2018-02-27T19:33:35Z | 2018-02-27T19:33:35Z | 0e73e240107caee3ffd1a1149f0150c390d43251 | 0 | 9c6a0eb28b122f7fcd4f08ceae24a2d001c7eb3f | 243093cf814ffaae2a9ce08215632500fbebcf52 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1924 | ||||
| 170081559 | MDExOlB1bGxSZXF1ZXN0MTcwMDgxNTU5 | 1925 | closed | 0 | flake8 passes | max-sixty 5635139 | I was still getting stickler errors for code I hadn't changed. Flake8 should now pass | 2018-02-20T01:09:05Z | 2018-02-22T02:20:58Z | 2018-02-20T18:04:59Z | 2018-02-20T18:04:59Z | 97f5778261e48391ba6772ca518cd2a51ff0ec83 | 0 | bbe009f02dfb36a0fd4e1e5684abf175202587a2 | 18a737b8ce7b57a903298b521ffacae116db11c5 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1925 | ||||
| 170212077 | MDExOlB1bGxSZXF1ZXN0MTcwMjEyMDc3 | 1927 | closed | 0 | Some backend tests require dask | max-sixty 5635139 | - [x] Closes https://github.com/pydata/xarray/issues/1923 (remove if there is no corresponding issue, which should only be the case for minor changes) - [x] Tests passed (for all non-documentation changes) LMK if these are the right ones - I basically added the decorator to anything that was failing. Though not sure we need to be 100% accurate here - worst case we could skip the file - either people are writing backend code and have dask installed, or they're not... | 2018-02-20T14:46:30Z | 2020-11-08T21:08:43Z | 2020-11-08T19:40:35Z | 36e09c25eaf7c8d096716a16a25d8fa6780b2425 | 0 | bf27a539cf18fe8025e4038829300eafb346ea6b | 7bf9df9d75c40bcbf2dd28c47204529a76561a3f | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1927 | |||||
| 171704476 | MDExOlB1bGxSZXF1ZXN0MTcxNzA0NDc2 | 1947 | closed | 0 | DOC: Contributing / isort | max-sixty 5635139 | @jhamman what are your thoughts on the flake8 instruction change? | 2018-02-27T15:54:53Z | 2018-02-27T23:21:44Z | 2018-02-27T23:21:41Z | 2018-02-27T23:21:41Z | f3bbb3ef6badcfe5d1f3b77c231846f0e79a93ea | 0 | c82b2155ffcd3db55f6b61619a601c9a6bf55b85 | 243093cf814ffaae2a9ce08215632500fbebcf52 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/1947 | ||||
| 177924628 | MDExOlB1bGxSZXF1ZXN0MTc3OTI0NjI4 | 2020 | closed | 0 | One pytest config | max-sixty 5635139 | Currently our pytest settings in `setup.cfg` are ignored, because they're overridden by the presence of a `pytest.ini` This restores pytest looking at `setup.cfg`, gives us a single place to put configs, and retains the 'no hypothesis by default'. Hypothesis is still run in travis, which specifically calls `pytest properties` | 2018-03-28T04:04:52Z | 2021-04-19T06:10:34Z | 2018-03-28T18:38:22Z | 2018-03-28T18:38:22Z | 8e4231a28d8385e95c156f17ccfefeab537f63ed | 0 | 1e4cc2c9e8cd112b1393a17bdf913eedafde193c | 7c2c43ce6b1792e1193635ab9b64fd248266f632 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2020 | ||||
| 178494830 | MDExOlB1bGxSZXF1ZXN0MTc4NDk0ODMw | 2031 | closed | 0 | Isin | max-sixty 5635139 | - [x] Tests added (for all bug fixes or enhancements) - [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 is an initial implementation of `isin`. It works for DataArrays, but isn't yet implemented further. I've been away from these sorts features for too long: Is there a canonical place to put these? What's the canonical approach to extending to datasets? I can see a few approaches in the code. | 2018-03-30T05:07:12Z | 2018-04-04T03:52:21Z | 2018-04-04T02:46:57Z | 2018-04-04T02:46:57Z | a5f7d6ac60e8e5682e2be739dd520b7a3bbd0fc7 | 0 | 43532dfef1fa338eb7170b38ddddf32cc4ccca34 | 8c194b695f07adad43e7a3aa5c59f53b01131807 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2031 | ||||
| 180988801 | MDExOlB1bGxSZXF1ZXN0MTgwOTg4ODAx | 2052 | closed | 0 | Docs formatting | max-sixty 5635139 | Winner of smallest PR of 2018  | 2018-04-11T18:24:19Z | 2018-04-11T23:12:28Z | 2018-04-11T21:37:47Z | 2018-04-11T21:37:47Z | e63e0e9766c68d7eef215da6f6d7b7dbaca4b652 | 0 | cb32489ba895d4517b31a0ebd3afa7ef8e409739 | 9b76f219ec314dcb0c9a310c097a34f5c751fdd6 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2052 | ||||
| 189900405 | MDExOlB1bGxSZXF1ZXN0MTg5OTAwNDA1 | 2174 | closed | 0 | Datasets more robust to non-string keys | max-sixty 5635139 | - [x] Closes #2172 & #2173 - [x] Tests added - [x] Tests passed - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API I don't think this is the most efficient way of doing this, though it does work. Any ideas for a more efficient implementation? | 2018-05-23T08:53:36Z | 2018-05-28T01:44:02Z | 2018-05-27T20:48:31Z | 2018-05-27T20:48:30Z | 847050026d45e2817960a37564bd8e909ecbdb05 | 0 | e2241df8b643559ee4b2f57482a87db48847cd28 | 04df50efefecaea729133c14082eb5e24491633e | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2174 | ||||
| 190989393 | MDExOlB1bGxSZXF1ZXN0MTkwOTg5Mzkz | 2193 | closed | 0 | Deprecated paths in tests | max-sixty 5635139 | Responding to a couple of warnings | 2018-05-28T19:56:48Z | 2018-05-29T03:05:28Z | 2018-05-29T03:05:25Z | 9944478e90d06886fe68f2f6ec5f52360fb0d257 | 0 | 0884a56ef06a5e3016cb95b4e311bc306e907bc7 | 847050026d45e2817960a37564bd8e909ecbdb05 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2193 | |||||
| 190990127 | MDExOlB1bGxSZXF1ZXN0MTkwOTkwMTI3 | 2194 | closed | 0 | Rename takes kwargs | max-sixty 5635139 | - [x] Tests added (for all bug fixes or enhancements) - [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) | 2018-05-28T20:03:21Z | 2018-05-29T03:05:12Z | 2018-05-29T03:05:09Z | 2018-05-29T03:05:09Z | fb7a43ea102c7706ad5d3bc8399264155cb273dd | 0 | 2bbd2e2364488e3c3978b6ef7744918fe25c5ca1 | 847050026d45e2817960a37564bd8e909ecbdb05 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2194 | ||||
| 196786848 | MDExOlB1bGxSZXF1ZXN0MTk2Nzg2ODQ4 | 2246 | closed | 0 | Small error in open_zarr docs | max-sixty 5635139 | I tried setting this up on GCS as an experiment, and found there's no `mode` kwarg to `open_zarr`. I'm not sure whether there are broader issues but thought I'd put this in regardless (also - if anyone has any experience in deploying xarray over https://github.com/dask/dask-kubernetes and GCS, I'd be interested in your experience. We're currently working with either a) BigQuery for big data or b) in-memory xarray for small data, and I was interested whether there's a way of retaining the xarray model for bigger data without too much overhead) | 2018-06-22T16:30:14Z | 2018-06-22T22:57:50Z | 2018-06-22T22:00:06Z | 2018-06-22T22:00:06Z | 9491318e29b478234e6f96c3547d724504b4a1bb | 0 | 979f401cb142ca22abd0211e05c4d53b5c98c274 | 73b476e4db6631b2203954dd5b138cb650e4fb8c | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2246 | ||||
| 205192916 | MDExOlB1bGxSZXF1ZXN0MjA1MTkyOTE2 | 2330 | closed | 0 | Supplying a dataset to the dataset constructor | max-sixty 5635139 | - [x] Closes https://github.com/pydata/xarray/issues/2056 - [x] Tests added (for all bug fixes or enhancements) - [x] Tests passed (for all non-documentation changes) - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API - Do we want to raise if coords / attrs are passed in addition to a Dataset? Do we want to warn for a couple versions first? - Is this the best way to implement this? Do we want a consistent method to "make this object a shallow copy of the object that's been passed in"? | 2018-07-31T17:51:45Z | 2018-09-25T21:00:17Z | 2018-09-25T21:00:12Z | ab988251d0c302a63a0160e683e8cd01fc908148 | 0 | 0692e35040fac4b536c9be9e0cca972f09f5a065 | 4de8dbc3b1de461c0c9d3b002e55d60b46d2e6d2 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2330 | |||||
| 205200269 | MDExOlB1bGxSZXF1ZXN0MjA1MjAwMjY5 | 2331 | closed | 0 | Better error message on invalid types | max-sixty 5635139 | - [x] Closes https://github.com/pydata/xarray/issues/1691 - [x] Tests added (for all bug fixes or enhancements) - [x] Tests passed (for all non-documentation changes) - [x] Fully documented | 2018-07-31T18:20:53Z | 2018-08-01T18:55:22Z | 2018-08-01T18:55:19Z | 2018-08-01T18:55:19Z | c86810b5ab3fc1cd47c1c0ed07e002b797b27eaf | 0 | 870cc03df79fd3595a160ee5b3eaf00f1e6d3b65 | 5d8670f6949fed60ab570075ae7dc67200f9ff51 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2331 | ||||
| 220856345 | MDExOlB1bGxSZXF1ZXN0MjIwODU2MzQ1 | 2467 | closed | 0 | Replace the last of unittest with pytest | max-sixty 5635139 | This replaces (by-and-large) any remaining unittest implementations with pytest implementations. This allows us to use fixtures on any test; the existing implementation does not let us use them on `TestCase` instances. It also directs future contributors away from using the legacy methods. Would be great to merge this fairly soon, as there's some chance of merge conflicts (which git may not catch - e.g. someone writing `self.assertEqual`). I'll try and chase down any test breaks as soon as possible. | 2018-10-06T01:15:45Z | 2018-10-06T18:09:56Z | 2018-10-06T17:09:14Z | 2018-10-06T17:09:14Z | bb87a9441d22b390e069d0fde58f297a054fd98a | 0 | 391b1df5859761fc19ba520a993f343751a8b148 | 3cef8d730d5bbd699a393fa15266064ebb9849e2 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2467 | ||||
| 220905190 | MDExOlB1bGxSZXF1ZXN0MjIwOTA1MTkw | 2469 | closed | 0 | isort | max-sixty 5635139 | Do we want to keep `isort` up to date? I think it's a balance between consistency vs. overhead | 2018-10-06T19:05:54Z | 2018-10-08T01:38:00Z | 2018-10-07T22:39:14Z | 2018-10-07T22:39:14Z | 3d65f02de7c0328029dd6c580f42ebeb7381579f | 0 | 122297a0c6ba142d9e2118e0285f7b3093b5d655 | bb87a9441d22b390e069d0fde58f297a054fd98a | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2469 | ||||
| 220909991 | MDExOlB1bGxSZXF1ZXN0MjIwOTA5OTkx | 2470 | closed | 0 | fill_value in shift | max-sixty 5635139 | - [x] Closes #https://github.com/pydata/xarray/issues/2451 - [x] Tests added - [x] Tests passed - [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) Should we be more defensive around which fill_values can be passed? Currently, if the array and float values have incompatible dtypes, we don't preemtively warn or cast, apart from the case of `np.nan`, which then uses the default filler | 2018-10-06T20:33:29Z | 2018-12-28T01:07:17Z | 2018-12-27T22:58:30Z | 2018-12-27T22:58:30Z | 85ded913d030dda8eb1f3ed18db76b32a9f9ca2d | 0 | fccfe4d4286947b29070306619c171b40832df03 | 2667deb74a30dc3bd88752a3ce5da590cf7ddd48 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2470 | ||||
| 220915824 | MDExOlB1bGxSZXF1ZXN0MjIwOTE1ODI0 | 2471 | closed | 0 | Tests passing in PR template | max-sixty 5635139 | Do we need this bullet? I don't generally ensure tests pass before submitting for review. (Although if I should be, then lmk) | 2018-10-06T22:48:07Z | 2018-10-08T01:37:45Z | 2018-10-07T22:31:17Z | 2018-10-07T22:31:17Z | 515324062cf6f182d20c1aad210e8627b0b4013f | 0 | 12826faf95f9264cda04a210ae4348e8a6270ea1 | bb87a9441d22b390e069d0fde58f297a054fd98a | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2471 | ||||
| 220966558 | MDExOlB1bGxSZXF1ZXN0MjIwOTY2NTU4 | 2472 | closed | 0 | Merge stable to master | max-sixty 5635139 | Ref https://github.com/pydata/xarray/pull/2466 | 2018-10-07T19:06:27Z | 2018-10-07T19:07:19Z | 2018-10-07T19:07:18Z | 2018-10-07T19:07:18Z | 3f697fe013dc510cebb6a64d0a2c760d6320573a | 0 | 3f697fe013dc510cebb6a64d0a2c760d6320573a | bb87a9441d22b390e069d0fde58f297a054fd98a | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2472 | ||||
| 225484096 | MDExOlB1bGxSZXF1ZXN0MjI1NDg0MDk2 | 2506 | closed | 0 | Iterate over data_vars only | max-sixty 5635139 | - [x] Closes #884 (remove if there is no corresponding issue, which should only be the case for minor changes) - [x] Tests added (for all bug fixes or enhancements) - [ ] 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) | 2018-10-24T17:14:50Z | 2018-10-25T15:27:03Z | 2018-10-25T15:26:59Z | 2018-10-25T15:26:59Z | d77db21071e6c2ec0267096d5313fcd349623446 | 0 | abe7bfa0a93ab00fd4bff8f70a84def708f78745 | b8c4b7862c87223f32e13d7c454a8f275998f828 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2506 | ||||
| 233700591 | MDExOlB1bGxSZXF1ZXN0MjMzNzAwNTkx | 2577 | closed | 0 | Concat docstring typo | max-sixty 5635139 | 2018-11-26T21:21:30Z | 2018-11-27T07:58:17Z | 2018-11-27T06:46:55Z | 2018-11-27T06:46:55Z | 483b8a0a89ea4be862488e51af8a1b3bc7f40356 | 0 | 93104f29a3744513f71b41f653fb2809afc34530 | a2a448dff8c053b1a3a137c64aedde520ac6de2a | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2577 | |||||
| 240718401 | MDExOlB1bGxSZXF1ZXN0MjQwNzE4NDAx | 2629 | closed | 0 | Flake fixed | max-sixty 5635139 | Towards https://github.com/pydata/xarray/issues/2627 | 2018-12-24T04:23:47Z | 2019-06-10T19:09:44Z | 2018-12-25T01:21:50Z | 2018-12-25T01:21:50Z | 2667deb74a30dc3bd88752a3ce5da590cf7ddd48 | 0 | a04ce50ec4886af27769fbea00220ca5cc90987c | d8d87d21786a7823b84d8f1f1e14f793fbd5352a | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2629 | ||||
| 240843996 | MDExOlB1bGxSZXF1ZXN0MjQwODQzOTk2 | 2632 | closed | 0 | Add flake check to travis | max-sixty 5635139 | - [x] Closes https://github.com/pydata/xarray/issues/2627 | 2018-12-25T07:36:38Z | 2018-12-30T06:26:26Z | 2018-12-30T00:10:17Z | 2018-12-30T00:10:17Z | 1545b50a3c8841b3f62c7bd59353d55aa2389697 | 0 | b995fca6cac1363ec1cddcba00dd27e714e98f4e | 2667deb74a30dc3bd88752a3ce5da590cf7ddd48 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2632 | ||||
| 241198379 | MDExOlB1bGxSZXF1ZXN0MjQxMTk4Mzc5 | 2635 | closed | 0 | silence import warning | max-sixty 5635139 | Next version can remove the Py2 path | 2018-12-27T17:56:18Z | 2018-12-28T07:10:44Z | 2018-12-28T07:10:41Z | 2018-12-28T07:10:41Z | bc5558e99a6323226fec5fb641281e86167b2e74 | 0 | 13c0bac4f370b5d91e1b83dd6f4bc0fd049a0bed | 2667deb74a30dc3bd88752a3ce5da590cf7ddd48 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2635 | ||||
| 242385984 | MDExOlB1bGxSZXF1ZXN0MjQyMzg1OTg0 | 2650 | closed | 0 | rolling_exp (nee ewm) | max-sixty 5635139 | - [x] Duplicate groupby / rolling interface - [x] Integrate with apply_ufunc, including orientation and coords - [x] Define com / span / alpha interface - [x] Implement for Variable & Dataset - [x] Docs | 2019-01-04T22:10:07Z | 2019-06-24T15:26:58Z | 2019-06-24T15:20:32Z | 2019-06-24T15:20:31Z | cfd821065341e386b3e4a1e6e09bf8d952ed0e2a | 0 | dd2a791d78335d4df5d21feaa53b378019c38f37 | 9c0bbf744a5235b4187f87de49175e6776d813cb | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2650 | ||||
| 244657599 | MDExOlB1bGxSZXF1ZXN0MjQ0NjU3NTk5 | 2674 | closed | 0 | Skipping variables in datasets that don't have the core dim | max-sixty 5635139 | ref https://github.com/pydata/xarray/pull/2650#issuecomment-454164295 This seems an ugly way of accomplishing the goal; any ideas for a better way of doing this? And stepping back, do others think a) it's helpful to skip variables in a dataset, and b) `apply_ufunc` should do this? | 2019-01-15T02:43:11Z | 2021-05-13T22:02:19Z | 2021-05-13T22:02:19Z | 0c8cdcae8445c8bd627d75e82e422562430b0175 | 0 | dfa40da0f41bd7cb20634653e38dc0a447535cf5 | 7bf9df9d75c40bcbf2dd28c47204529a76561a3f | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2674 | |||||
| 244790249 | MDExOlB1bGxSZXF1ZXN0MjQ0NzkwMjQ5 | 2677 | closed | 0 | Small typo | max-sixty 5635139 | @fujiisoup is this a small typo? | 2019-01-15T13:15:31Z | 2019-01-15T15:40:19Z | 2019-01-15T13:29:54Z | 14d4334691044ff28168a4eba507e5131be7db66 | 0 | 04aa31dbccc329ddd29c0ad8fdfc2910dd7364f4 | f13536c965d02bb2845da31e909899a90754b375 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2677 | |||||
| 244945042 | MDExOlB1bGxSZXF1ZXN0MjQ0OTQ1MDQy | 2682 | closed | 0 | 2019 copyright | max-sixty 5635139 | 2019-01-15T21:32:48Z | 2019-01-16T11:50:44Z | 2019-01-16T09:35:52Z | 2019-01-16T09:35:52Z | 5a96460dcba1bdfcedb3f2950628edca8a939e87 | 0 | 9d86cc6a821d03c9efe2460c06e431963135980e | f13536c965d02bb2845da31e909899a90754b375 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2682 | |||||
| 245173016 | MDExOlB1bGxSZXF1ZXN0MjQ1MTczMDE2 | 2684 | closed | 0 | Config for closing stale issues | max-sixty 5635139 | - [x] Closes https://github.com/pydata/xarray/issues/2681 Initially set at two years, and max rate of one / hour - we can make more aggressive when we know it's working | 2019-01-16T14:47:47Z | 2019-01-23T02:52:25Z | 2019-01-23T02:50:00Z | 2019-01-23T02:50:00Z | 1e67c230649a0ccb9525540d5420746d77629f4d | 0 | ee56500c5c0d450ff2f48578bc0f23af1e3f9551 | 385b36cdd34431b4f6f14aad1f222f989e7e2de2 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2684 | ||||
| 245630951 | MDExOlB1bGxSZXF1ZXN0MjQ1NjMwOTUx | 2687 | closed | 0 | Enable resampling on PeriodIndex | max-sixty 5635139 | This allows resampling with `PeriodIndex` objects by keeping the `group` as an index rather than coercing to a DataArray (which coerces any non-native types to objects) I'm still getting one failure around the name of the IndexVariable still being `__resample_dim__` after resample, but wanted to socialize the approach of allowing a `name` argument to `IndexVariable` - is this reasonable? - [x] Closes https://github.com/pydata/xarray/issues/1270 - [x] Tests added - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API | 2019-01-17T20:13:25Z | 2023-11-17T20:38:44Z | 2023-11-17T20:38:44Z | 18f9e0a37e529443a84e20292fd71b0799f9e606 | 0 | cc7bfe979cabab466ac181b655360461d01168a4 | d1e4164f3961d7bbb3eb79037e96cae14f7182f8 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2687 | |||||
| 247016198 | MDExOlB1bGxSZXF1ZXN0MjQ3MDE2MTk4 | 2698 | closed | 0 | add line break to stale message | max-sixty 5635139 | Currently the message is interpreted as a single line Please post any other feedback | 2019-01-23T15:44:37Z | 2019-01-23T16:17:39Z | 2019-01-23T16:17:36Z | 2019-01-23T16:17:36Z | e53f21ce6c9ad8c74b1f6cc9dd00d374688ca0fe | 0 | 51553f43f928a57e29737d66dc1e4e41d2b67082 | 1e67c230649a0ccb9525540d5420746d77629f4d | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2698 | ||||
| 247169528 | MDExOlB1bGxSZXF1ZXN0MjQ3MTY5NTI4 | 2701 | closed | 0 | Probot stale tweak | max-sixty 5635139 | I think this requires a label Thanks for everyone's understanding re needing to test it live | 2019-01-24T01:08:35Z | 2019-01-24T01:08:49Z | 2019-01-24T01:08:47Z | 2019-01-24T01:08:47Z | 79fa060dd6b567e8aa3606b8b8cc0c54d1b14acb | 0 | c1eb81ec6bb69cf1fd0c62687df8cb595431157e | ddacf405fb256714ce01e1c4c464f829e1cc5058 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2701 | ||||
| 247388731 | MDExOlB1bGxSZXF1ZXN0MjQ3Mzg4NzMx | 2703 | closed | 0 | deprecate compat & encoding | max-sixty 5635139 | Still need to adjust the tests - [x] Closes https://github.com/pydata/xarray/issues/1188 - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API | 2019-01-24T16:14:21Z | 2019-02-01T03:16:13Z | 2019-02-01T03:16:10Z | 2019-02-01T03:16:10Z | d634f64c818d84dfc6fcc0f7fef81e4bb2094540 | 0 | 69436a91a0752b3648fd831d07ade8df3a02aa1f | 5527f693fc0a39cd04db7aa6b4fd95edbe722921 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2703 | ||||
| 248922709 | MDExOlB1bGxSZXF1ZXN0MjQ4OTIyNzA5 | 2727 | closed | 0 | silence a couple of warnings in tests | max-sixty 5635139 | The only other warning is: ``` xarray/tests/test_dataset.py::TestDataset::test_convert_dataframe_with_many_types_and_multiindex /Users/maximilian/workspace/xarray/xarray/core/dataset.py:3146: FutureWarning: Converting timezone-aware DatetimeArray to timezone-naive ndarray with 'datetime64[ns]' dtype. In the future, this will return an ndarray with 'object' dtype where each element is a 'pandas.Timestamp' with the correct 'tz'. To accept the future behavior, pass 'dtype=object'. To keep the old behavior, pass 'dtype="datetime64[ns]"'. data = np.asarray(series).reshape(shape) /usr/local/lib/python3.7/site-packages/pandas/core/apply.py:286: FutureWarning: Converting timezone-aware DatetimeArray to timezone-naive ndarray with 'datetime64[ns]' dtype. In the future, this will return an ndarray with 'object' dtype where each element is a 'pandas.Timestamp' with the correct 'tz'. To accept the future behavior, pass 'dtype=object'. To keep the old behavior, pass 'dtype="datetime64[ns]"'. results[i] = self.f(v) ``` I'm not sure what we want to do here - potentially we should make a choice between: - the worse behavior of `object` - accepting the coercing to naive datetimes - supporting pandas extension arrays | 2019-01-30T15:37:41Z | 2019-01-30T19:06:37Z | 2019-01-30T19:06:34Z | 2019-01-30T19:06:34Z | 5527f693fc0a39cd04db7aa6b4fd95edbe722921 | 0 | 1cbdb98d3988cefd6dfe24a2c42bb296c8f4b36d | e8bf4bf9a744148f1f6586cabe7f5c5ef6e9bf26 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2727 | ||||
| 263037022 | MDExOlB1bGxSZXF1ZXN0MjYzMDM3MDIy | 2831 | closed | 0 | Enable python 3.5.0-3.5.2 | max-sixty 5635139 | - [x] Closes some of https://github.com/pydata/xarray/issues/2830 | 2019-03-20T21:03:51Z | 2019-03-22T15:12:27Z | 2019-03-22T04:37:25Z | 2019-03-22T04:37:25Z | 742ed3984f437982057fd46ecfb0bce214563cb8 | 0 | ba38ee7655ff210a1a51bcd40ef8dd4796472409 | 164d20abb6ffc35eb3f314ce7fb5b9600cf9de3f | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2831 | ||||
| 263054798 | MDExOlB1bGxSZXF1ZXN0MjYzMDU0Nzk4 | 2832 | closed | 0 | Small fix: use == to compare strings | max-sixty 5635139 | `is` relies on interning, which is almost always OK for small strings, but reliant on language implementations (unless there's something I'm missing about `.kind`?) | 2019-03-20T22:04:39Z | 2019-03-23T21:30:22Z | 2019-03-22T01:12:51Z | 2019-03-22T01:12:51Z | 8126d3e623667930b1df43c2d936a0ba52a6ca19 | 0 | cdac34972b7a55b8f21548d0327d9842ab91cee2 | 164d20abb6ffc35eb3f314ce7fb5b9600cf9de3f | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2832 | ||||
| 268138985 | MDExOlB1bGxSZXF1ZXN0MjY4MTM4OTg1 | 2875 | closed | 0 | DOC: More on pandas comparison | max-sixty 5635139 | Follow up from the mailing list: - Added some more thoughts on the multi-dimensional comparison. Some of this is opinionated (in concepts not arguments) so I'd appreciate feedback on both the concepts and language. - Removed some of the specific comparison with `NDPanel` etc, given those are removed - Placeholder for something on the Explicit API (wanted to get this version out, consistent with me leaving less work hanging) | 2019-04-07T21:24:44Z | 2023-09-28T16:46:14Z | 2023-09-28T16:46:14Z | 48aa727e6ac45a97949e4d7cb28fabe1de208957 | 1 | d80c0f39e57671ee20e0f05d768b94cd9e01e10f | d1e4164f3961d7bbb3eb79037e96cae14f7182f8 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2875 | |||||
| 275818978 | MDExOlB1bGxSZXF1ZXN0Mjc1ODE4OTc4 | 2939 | closed | 0 | List formatting in docs | max-sixty 5635139 | Existing output didn't format correctly  | 2019-05-03T19:10:29Z | 2019-05-03T20:19:29Z | 2019-05-03T20:14:28Z | 2019-05-03T20:14:28Z | dd99b7d7d8576eefcef4507ae9eb36a144b60adf | 0 | d557569a96eed0c4a95f5e5ab0a169159fd79673 | 2633b1e5cbc21cd414e588571ab7be26df8e8dae | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2939 | ||||
| 282112948 | MDExOlB1bGxSZXF1ZXN0MjgyMTEyOTQ4 | 2987 | closed | 0 | Implement @ operator for DataArray | max-sixty 5635139 | - [x] Closes https://github.com/pydata/xarray/issues/1053 - [x] Tests added - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API Is it really this easy? What am I missing? | 2019-05-24T18:14:20Z | 2019-06-01T20:00:24Z | 2019-06-01T19:42:21Z | 2019-06-01T19:42:20Z | 5b3a41d5761edb2240df5a4475196e4939b33719 | 0 | ec4769e376e2318a8001329f55424aef38693745 | 0811141e8f985a1f3b95ead92c3850cc74e160a5 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2987 | ||||
| 282126853 | MDExOlB1bGxSZXF1ZXN0MjgyMTI2ODUz | 2988 | closed | 0 | Remove deprecated pytest.config usages | max-sixty 5635139 | <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Tests added - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API I need to confirm whether this works with an installed version of xarray, because of https://github.com/pytest-dev/pytest/issues/1596. If pytest doesn't pick up this config, it will run all tests, because the default is to not skip. I know I've generally been the point person for pytest - let me know if anyone has an immediate solution for this though | 2019-05-24T19:00:11Z | 2019-06-14T23:06:46Z | 2019-05-25T02:01:32Z | 2019-05-25T02:01:31Z | 7edf2e20d4c898fbb637da3b3e6ded15808e040b | 0 | 18c09838bc9d89e7528b11d8a95de19644798517 | 0811141e8f985a1f3b95ead92c3850cc74e160a5 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/2988 | ||||
| 286777817 | MDExOlB1bGxSZXF1ZXN0Mjg2Nzc3ODE3 | 3010 | closed | 0 | Use flake8 rather than pycodestyle | max-sixty 5635139 | - [x] Closes https://github.com/pydata/xarray/issues/2990 - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API I also ran `isort`, which created more changes that I would have hoped. Lmk if that's OK. We could also enable `isort` by default. It's a balance: it reduces the chance of merge conflicts and adds automatic consistency, but at the cost of making first-time contributions a bit more difficult. | 2019-06-10T18:10:46Z | 2019-06-12T04:58:59Z | 2019-06-12T04:56:37Z | 2019-06-12T04:56:37Z | 3429ca2aa2a07cd77797f5a4c036d6a325f2003f | 0 | aa7400c3d82f17fd72efae8cfb4ed4e5e532b0a1 | 43834ac8186a851b7ea5aed8657b72d62fa3695f | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3010 | ||||
| 286790489 | MDExOlB1bGxSZXF1ZXN0Mjg2NzkwNDg5 | 3011 | closed | 0 | Pytest capture uses match, not message | max-sixty 5635139 | - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API `message` was always going being ignored, and with the newer pytest version raises a warning that an unknown kwarg is supplied | 2019-06-10T18:46:43Z | 2019-06-11T15:01:23Z | 2019-06-11T15:01:19Z | 2019-06-11T15:01:19Z | f3efb5bdaf87c5301106cd1122b14d131c7d464b | 0 | dc07f4a4cb5a7a137e5fbe801172e508ffb141d4 | 43834ac8186a851b7ea5aed8657b72d62fa3695f | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3011 | ||||
| 286813537 | MDExOlB1bGxSZXF1ZXN0Mjg2ODEzNTM3 | 3014 | closed | 0 | Dask-dev tests to allow_failures in travis | max-sixty 5635139 | In lieu of fixing the issues, move these into allow_failures | 2019-06-10T19:54:46Z | 2019-06-11T04:03:58Z | 2019-06-11T02:45:48Z | 2019-06-11T02:45:48Z | 43834ac8186a851b7ea5aed8657b72d62fa3695f | 0 | d5561cc1ba90e9534030eff239c9daa96b48863d | adbd59a0498cce298d88d9383837c968bebae538 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3014 | ||||
| 287168294 | MDExOlB1bGxSZXF1ZXN0Mjg3MTY4Mjk0 | 3016 | closed | 0 | Pandas labels deprecation | max-sixty 5635139 | Should I still add a `whatsnew`? It's very small and very internal | 2019-06-11T16:24:43Z | 2019-06-12T00:49:31Z | 2019-06-11T22:58:26Z | 2019-06-11T22:58:26Z | fda60563bbca7eea6fabd6603750f359e1ad00ef | 0 | 8b31e868893b6f7a39536194dd3fbc6e2fd96a93 | f3efb5bdaf87c5301106cd1122b14d131c7d464b | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3016 | ||||
| 287558117 | MDExOlB1bGxSZXF1ZXN0Mjg3NTU4MTE3 | 3019 | closed | 0 | Update issue templates | max-sixty 5635139 | This: - Updates to the [newer GitHub format](https://help.github.com/en/articles/about-issue-and-pull-request-templates) - Strengthens the language around MCVE. It doesn't say people *have* to, but makes it less of a suggestion - Only contains 'Bug Report'. Should we have others? I don't immediately see how they'd be different (I realize because I did this from the GH website, it created from this repo rather than my own fork. That's a mistake.) | 2019-06-12T15:19:04Z | 2019-06-15T03:35:23Z | 2019-06-15T03:35:17Z | 2019-06-15T03:35:16Z | c2a2a6efcaf2d279c78da4ba3a87ea96afe78be0 | 0 | 20e47531f5f842aa2d6216ba440d10ee1f39500e | 3429ca2aa2a07cd77797f5a4c036d6a325f2003f | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3019 | ||||
| 288510873 | MDExOlB1bGxSZXF1ZXN0Mjg4NTEwODcz | 3023 | closed | 0 | Add pytest markers to avoid warnings | max-sixty 5635139 | These are now required; I was getting warnings ``` /usr/local/lib/python3.7/site-packages/_pytest/mark/structures.py:337: PytestUnknownMarkWarning: Unknown pytest.mark.network - is this a typo? You can register custom marks to avoid this warning - for details, see https://docs.pytest.org/en/latest/mark.html` ``` | 2019-06-14T23:24:03Z | 2019-06-15T01:29:45Z | 2019-06-15T00:34:04Z | 2019-06-15T00:34:04Z | 85fc44156722891b333f1b559ed2bb5e33f87fa8 | 0 | 44d65ee72e48e0b3a1e43b743ce04ac16970a82c | 7e4bf8623891c4e564bbaede706e1d69c614b74b | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3023 | ||||
| 288524748 | MDExOlB1bGxSZXF1ZXN0Mjg4NTI0NzQ4 | 3024 | closed | 0 | Check types in travis | max-sixty 5635139 | As part of https://github.com/pydata/xarray/pull/2929#issuecomment-502302695, I looked at enabling travis to check types. What do people think? As a more cautious option I could add to `allowed_failures` for the moment | 2019-06-15T02:19:28Z | 2019-06-18T14:30:14Z | 2019-06-18T05:12:48Z | 2019-06-18T05:12:48Z | 4c758e6ad282228ec52c277471db7cfb4f1f050f | 0 | 5ece56d0d181b56cf94d1c2371a6ebd4a185206e | c2a2a6efcaf2d279c78da4ba3a87ea96afe78be0 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3024 | ||||
| 288652287 | MDExOlB1bGxSZXF1ZXN0Mjg4NjUyMjg3 | 3025 | closed | 0 | Dask-dev tests reenabled | max-sixty 5635139 | ref https://github.com/pydata/xarray/issues/3009#issuecomment-502432894 | 2019-06-16T21:11:48Z | 2019-06-24T04:33:15Z | 2019-06-23T11:47:04Z | 2019-06-23T11:47:04Z | 56fc325ae029b5aa8fc4556197103a1a2eb31702 | 0 | 7e4054cee98e5b860eb390a61169751cfc13711b | ff4198865b42ee2f6f99f3f6f83fed68ef4ffbc7 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3025 | ||||
| 288965348 | MDExOlB1bGxSZXF1ZXN0Mjg4OTY1MzQ4 | 3029 | closed | 0 | Fix pandas-dev tests | max-sixty 5635139 | Currently pandas-dev tests get 'stuck' on the conda install. The last instruction to run is the standard install: ``` $ if [[ "$CONDA_ENV" == "docs" ]]; then conda env create -n test_env --file doc/environment.yml; elif [[ "$CONDA_ENV" == "lint" ]]; then conda env create -n test_env --file ci/requirements-py37.yml; else conda env create -n test_env --file ci/requirements-$CONDA_ENV.yml; fi ``` And after installing the libraries, [it prints this and then stops](https://travis-ci.org/max-sixty/xarray/jobs/546491330): ``` Preparing transaction: - - done Verifying transaction: | / \ | / - \ | / / done Executing transaction: \ | / - \ | / - \ | / - \ | / - \ | / - \ | / / - \ | / - \ done No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself. ``` I'm not that familiar with conda. Anyone have any ideas as to why this would fail while the other builds would succeed? | 2019-06-17T18:15:16Z | 2019-06-28T15:31:33Z | 2019-06-28T15:31:28Z | 0eb28c3cc5dd20d176c299d77f23957384c51bee | 0 | 2c5f59aa576dace2c4d5b0b26c141b8f2b9727b0 | c2a2a6efcaf2d279c78da4ba3a87ea96afe78be0 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3029 | |||||
| 291758288 | MDExOlB1bGxSZXF1ZXN0MjkxNzU4Mjg4 | 3044 | closed | 0 | Upgrade mypy & DataWithCoords check | max-sixty 5635139 | Quicker than expected follow-up to the typing PR, but realized that a newer version of mypy catches https://github.com/pydata/xarray/blob/master/xarray/core/common.py#L831 as `__getitem__` isn't implemented | 2019-06-25T22:44:04Z | 2019-06-26T04:11:38Z | 2019-06-26T04:04:40Z | 2019-06-26T04:04:40Z | 8c73852541a8a96232e98af9f24365551cf3ad40 | 0 | 3096646a95243e77727e6b9a61d4e7b0b0d25edc | d3f6db9d1eee54b51d2b0cd9a0a01a411d2148b7 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3044 | ||||
| 292568988 | MDExOlB1bGxSZXF1ZXN0MjkyNTY4OTg4 | 3051 | closed | 0 | pytest deprecation | max-sixty 5635139 | We weren't trying to do this in the first place, so somewhat coincidental: ``` xarray/tests/test_combine.py::TestManualCombine::test_manual_concat_too_many_dims_at_once /home/vsts/work/1/s/xarray/tests/test_combine.py:347: PytestDeprecationWarning: raises(..., 'code(as_a_string)') is deprecated, use the context manager form or use `exec()` directly ``` | 2019-06-27T19:18:44Z | 2021-04-19T06:10:35Z | 2019-06-27T20:25:01Z | 2019-06-27T20:25:01Z | a52110cde96cdf78b59282d577ece23682975b2e | 0 | 463eb72776e6a822e6e0f574994f7732ae523063 | c729121489c808a351b79c707743d97cdedd22b9 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3051 | ||||
| 296741850 | MDExOlB1bGxSZXF1ZXN0Mjk2NzQxODUw | 3097 | closed | 0 | Remove old issue template, small changes to current template | max-sixty 5635139 | 2019-07-11T16:55:21Z | 2021-04-19T06:10:35Z | 2019-07-14T05:32:41Z | 2019-07-14T05:32:41Z | 960a27e38f95b8f35b11f0ae4693258f9bf0959d | 0 | 8660cd9af25cf5a12c5bd724b5a793f620c06606 | 8f0d9e5c9909c93a90306ed7cb5a80c1c2e1c97d | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3097 | |||||
| 298698863 | MDExOlB1bGxSZXF1ZXN0Mjk4Njk4ODYz | 3140 | closed | 0 | Disable codecov comments | max-sixty 5635139 | closes https://github.com/pydata/xarray/issues/3098 | 2019-07-17T22:57:05Z | 2021-04-19T06:10:33Z | 2019-07-18T01:12:38Z | 2019-07-18T01:12:38Z | c46fae1a2ea5572316007d7e4fe84da4b7ec9f32 | 0 | 8cf28ef9467f77955cb764f761241c07027da6a1 | 8da3f67ea583e0588291162067229b2f3ce2993e | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3140 | ||||
| 298998116 | MDExOlB1bGxSZXF1ZXN0Mjk4OTk4MTE2 | 3142 | closed | 0 | Black | max-sixty 5635139 | From https://github.com/pydata/xarray/issues/3092 - [x] Reformat code - [x] CI checks - [x] Short instructions for how to merge an existing PR (i.e. avoid manual merge resolution) - Not sure if there's magic here - I think people would just have to format their code and then hope git can resolve (i.e. because there would still be no common parent)? - [x] Black badge - [x] Do we want to keep `flake8` checks? Black is mostly stricter but not always, e.g. on lines at the end of files. (+0.3 from me to use only `black` and stop using `flake8`) ~- [ ] Do we want to include `isort`? (-0.1 from me, even though I like the tool)~ | 2019-07-18T16:35:05Z | 2019-08-08T20:55:14Z | 2019-08-08T20:54:34Z | 2019-08-08T20:54:34Z | d089df385e737f71067309ff7abae15994d581ec | 0 | 6ec30779a7ade1dcdc230f208c1d04026dfd79b1 | f172c6738ae4bc9802e08d355ea05ea6c47527ab | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3142 | ||||
| 299107543 | MDExOlB1bGxSZXF1ZXN0Mjk5MTA3NTQz | 3145 | closed | 0 | Fix h5py version printing | max-sixty 5635139 | <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Closes https://github.com/pydata/xarray/issues/3144 I surrounded the whole check for h5py & netcdf with a blanket try / except, consistent with the other modules (but maybe too broad? | 2019-07-18T21:57:01Z | 2019-07-19T17:54:27Z | 2019-07-19T07:32:27Z | 2019-07-19T07:32:27Z | 9afe4d0cc1c5bee68a3e28887125a31336e4f58f | 0 | e13db0f818c41f48fde6e26df84772fbc563e8a2 | 5111a9cba9f3937eba1064ce5d921f8a60f71c03 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3145 | ||||
| 299108747 | MDExOlB1bGxSZXF1ZXN0Mjk5MTA4NzQ3 | 3146 | closed | 0 | Issue template: 'about' field is required | max-sixty 5635139 | If anyone has suggestions for better language... | 2019-07-18T22:01:01Z | 2019-07-19T17:54:20Z | 2019-07-19T17:52:43Z | 2019-07-19T17:52:43Z | 118f4d996e7711c9aced916e6049af9f28d5ec66 | 0 | 044313b2b592544e341c49b6672c8642f978161b | 5111a9cba9f3937eba1064ce5d921f8a60f71c03 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3146 | ||||
| 305690842 | MDExOlB1bGxSZXF1ZXN0MzA1NjkwODQy | 3193 | closed | 0 | Small updates to contributing.rst | max-sixty 5635139 | I'm not sure if people really use this? If they do, it could use another run through. Potentially some of our explanations could become links to better maintained docs; e.g. how to use git / pytest This makes a couple of small tweaks, in pursuit of incrementalism :) | 2019-08-08T18:12:43Z | 2019-08-09T16:12:30Z | 2019-08-09T10:40:23Z | 2019-08-09T10:40:23Z | d3f1ced1aa84cb0a0f3e47e7ee67492e203fcce5 | 0 | 6e7de443e8062698c4c8e872cfd473c44472be9c | f172c6738ae4bc9802e08d355ea05ea6c47527ab | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3193 | ||||
| 305751374 | MDExOlB1bGxSZXF1ZXN0MzA1NzUxMzc0 | 3194 | closed | 0 | Remove future statements | max-sixty 5635139 | Not sure why these weren't picked up in some of the previous python3-ifying | 2019-08-08T21:14:35Z | 2019-08-09T04:33:11Z | 2019-08-09T04:33:08Z | 2019-08-09T04:33:08Z | 58001d72000b3d4a872cc63bd10a5b48d27658b2 | 0 | 4df038747410dad575531245cc6d14cf7c81da7d | d089df385e737f71067309ff7abae15994d581ec | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3194 | ||||
| 305772178 | MDExOlB1bGxSZXF1ZXN0MzA1NzcyMTc4 | 3195 | closed | 0 | Update black instructions | max-sixty 5635139 | This needed updating with the relevant commit post-black change I also added a line to apply the patch of manual changes we made on top of the black changes. It makes the list of steps a bit burdensome. But I've tested them a couple of times and, where people have lots of code changes, it's still going to be much easier than resolving manually. I generally wouldn't want to suggest people curl data from the internet (even if we trust the individual). I think it's probably OK in this instance: the address contains a hash of the contents, and it's only being fed into `git apply -`, not executed. But lmk if that's still a security concern. I'll update the issue I opened on `black` with the above issue; we should have done one commit with only the `black` changes, and then another with any manual changes. | 2019-08-08T22:28:59Z | 2019-08-09T00:27:28Z | 2019-08-09T00:27:09Z | 2019-08-09T00:27:09Z | 5b36e80b5a5e790e1c533cae4382234c18bb37a1 | 0 | ce89ec20bbc37d27e5e90f2723c1647fe17a34fd | d089df385e737f71067309ff7abae15994d581ec | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3195 | ||||
| 306241974 | MDExOlB1bGxSZXF1ZXN0MzA2MjQxOTc0 | 3201 | closed | 0 | fix precommit file | max-sixty 5635139 | CC @crusaderky | 2019-08-10T22:15:32Z | 2019-08-10T22:15:42Z | 2019-08-10T22:15:39Z | 2019-08-10T22:15:39Z | 362ae55b32a0c3b298de184b0a91188e0e02df1e | 0 | 8ed45186971eaf2ed14ecf606719e9eec5b8901c | befc72f052a189c114695b4ae9a1c66533617336 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3201 | ||||
| 310584059 | MDExOlB1bGxSZXF1ZXN0MzEwNTg0MDU5 | 3260 | closed | 0 | Raise on inplace=True | max-sixty 5635139 | <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Removes inplace, and relatedly closes https://github.com/pydata/xarray/issues/1997 (and maybe https://github.com/pydata/xarray/issues/2951) - [x] Passes `black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API - [x] Remove from doc strings, docs Do we want to raise an explicit error for another minor release (rather than remove all traces of `inplace`)? I'd vote +0.5 - it's likely that some people don't check deprecation warnings and this states the problem clearly What do we want to do re `.update` (#2951)? | 2019-08-24T04:55:08Z | 2019-08-26T18:44:00Z | 2019-08-26T18:43:51Z | 2019-08-26T18:43:51Z | e3b3bed2c2e27eb74adc2b7f80c365c2928cd78b | 0 | 277fdd95e90e046b57595cd9639a02faac8ad049 | 5f55d41a05618e6091061dfb83fe745ed6008997 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3260 | ||||
| 310634500 | MDExOlB1bGxSZXF1ZXN0MzEwNjM0NTAw | 3261 | closed | 0 | Remove sel_points | max-sixty 5635139 | <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Passes `black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API Mentioned in https://github.com/pydata/xarray/issues/3257 Here I just removed them rather than an explicit error (as opposed to https://github.com/pydata/xarray/pull/3260), given my prior that they're not used so much* \* any way of seeing how often methods are used in other projects - e.g. a service that collects usage stats from other GH repos which use a given dependency? Could be an interesting side project... | 2019-08-24T19:08:07Z | 2019-08-25T17:55:57Z | 2019-08-25T17:55:47Z | 2019-08-25T17:55:47Z | 5f55d41a05618e6091061dfb83fe745ed6008997 | 0 | 0616379d8a7bd0852cf4b4fd263c3861c8122483 | 3f1b879c93426825f8c378f043afff8259dc8d28 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3261 | ||||
| 315269620 | MDExOlB1bGxSZXF1ZXN0MzE1MjY5NjIw | 3292 | closed | 0 | Remove some deprecations | max-sixty 5635139 | <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Closes some of #3280 - [x] Passes `black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API | 2019-09-08T12:14:31Z | 2019-09-08T22:58:28Z | 2019-09-08T22:58:16Z | 2019-09-08T22:58:16Z | d1260443d065c3f2ec3f8eb3d999c59a695b35a2 | 0 | d447e61b9ca1caeaea28e169921b2eefb5604505 | 0a046dbdeff409728b4e9bf55fba9d2aae9acd07 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3292 | ||||
| 315421106 | MDExOlB1bGxSZXF1ZXN0MzE1NDIxMTA2 | 3294 | closed | 0 | Compat and encoding deprecation to 0.14 | max-sixty 5635139 | Per https://github.com/pydata/xarray/issues/3280 | 2019-09-09T08:43:23Z | 2019-10-19T17:50:00Z | 2019-09-09T19:17:34Z | 2019-09-09T19:17:34Z | 69c7e01e5167a3137c285cb50d1978252bb8bcbf | 0 | 89d65f5a53e71a07ea90a7652f8c475eb0bbcc75 | e38ca0f168ebc2c52857a2abd45572a6e92beca8 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3294 | ||||
| 330041636 | MDExOlB1bGxSZXF1ZXN0MzMwMDQxNjM2 | 3418 | closed | 0 | change ALL_DIMS to equal ellipsis | max-sixty 5635139 | - [x] Closes https://github.com/pydata/xarray/issues/3414 - [x] Passes `black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API This is a more drastic version of the suggested change, making `xr.ALL_DIMS` equal the ellipsis, `...`. The only downside I can see is that printing `xr.ALL_DIMS` will print `...`. The upside is that we get compat 'for free' | 2019-10-19T17:46:55Z | 2019-10-25T17:16:33Z | 2019-10-25T15:15:47Z | 2019-10-25T15:15:47Z | 79b3cdd3822c79ad2ee267f4d5082cd91c7f714c | 0 | 48595c3cbeab1615f1b71668d2b77676cd34cc84 | 652dd3ca77dd19bbd1ab21fe556340c1904ec382 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3418 | ||||
| 330044066 | MDExOlB1bGxSZXF1ZXN0MzMwMDQ0MDY2 | 3419 | closed | 0 | Python3.6 idioms | max-sixty 5635139 | - [x] Passes `black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API Use python 3.6+ idioms; most changes are f-strings Mostly from `pyupgrade --py36-plus **/*.py` | 2019-10-19T18:15:48Z | 2019-10-21T01:32:07Z | 2019-10-21T00:16:58Z | 2019-10-21T00:16:58Z | 3c462b9663bfd9f609b567a7743465aa1b413b1e | 0 | 529c8f0dbc9ac5e8af96d6033b3c0fb6e57a1776 | 9886e3c84051772ce62a50aa7067ee2f5b68f8cd | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3419 | ||||
| 330164084 | MDExOlB1bGxSZXF1ZXN0MzMwMTY0MDg0 | 3421 | closed | 0 | Allow ellipsis (...) in transpose | max-sixty 5635139 | <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Closes https://github.com/pydata/xarray/issues/1081#issuecomment-540477534 - [x] Tests added - [x] Passes `black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API HT to @crusaderky for the idea! | 2019-10-20T22:15:12Z | 2019-10-28T23:47:15Z | 2019-10-28T21:12:49Z | 2019-10-28T21:12:49Z | 02288b4e0cb4e300e402d96bbbdba68db6eeb41f | 0 | 86ad50626f2b846e1fa06dc2f4f709b26813cccc | fb0cf7b5fe56519a933ffcecbce9e9327fe236a6 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3421 | ||||
| 330183926 | MDExOlB1bGxSZXF1ZXN0MzMwMTgzOTI2 | 3422 | closed | 0 | Whatsnew for #3419 | max-sixty 5635139 | 2019-10-21T01:39:06Z | 2019-10-21T11:13:28Z | 2019-10-21T08:52:37Z | 2019-10-21T08:52:37Z | b0c336f6b4b8d425e5c89d6f75f561823806137b | 0 | 57a536cdf8bb18f7832c3493d820235c5dc4fc37 | 2984415e9884c12f407ac39c06dffb822c540bb3 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3422 | |||||
| 332792936 | MDExOlB1bGxSZXF1ZXN0MzMyNzkyOTM2 | 3451 | closed | 0 | Remove deprecated behavior from dataset.drop docstring | max-sixty 5635139 | I'm less up to speed on this behavior, but IIUC this part of the docstring refers to [deprecated behavior](https://github.com/pydata/xarray/compare/master...max-sixty:drop-docstring?expand=1#diff-921db548d18a549f6381818ed08298c9R3586-R3592)—is that correct or am I missing something? xref https://github.com/pydata/xarray/issues/3266 | 2019-10-26T19:06:16Z | 2019-10-29T15:03:53Z | 2019-10-29T14:49:17Z | 2019-10-29T14:49:16Z | 74ca69a3b7b53d2b8cc8c88ddaf0fe8c6c7bbf6c | 0 | acbe79ef0f0f7c728a11c264b5e602a7057f40fe | fb0cf7b5fe56519a933ffcecbce9e9327fe236a6 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3451 | ||||
| 333675348 | MDExOlB1bGxSZXF1ZXN0MzMzNjc1MzQ4 | 3456 | closed | 0 | upgrade black verison to 19.10b0 | max-sixty 5635139 | Black version 19.10b0 recently came out. Looks like the biggest change is assigning to a one-item-tuple | 2019-10-29T15:03:30Z | 2019-10-29T20:36:13Z | 2019-10-29T15:34:34Z | 2019-10-29T15:34:34Z | 278d2e6af6abd933dd1d43ac3ae70bc306412ae1 | 0 | c3f8c39b604ec485387577c9d394cee671204c93 | 74ca69a3b7b53d2b8cc8c88ddaf0fe8c6c7bbf6c | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3456 | ||||
| 333698043 | MDExOlB1bGxSZXF1ZXN0MzMzNjk4MDQz | 3457 | closed | 0 | Merge stable into master | max-sixty 5635139 | 2019-10-29T15:37:27Z | 2019-10-29T15:40:09Z | 2019-10-29T15:37:49Z | 2019-10-29T15:37:49Z | 80e4e8973b968c9856052c93c0dc1e3162682f8e | 0 | d197c8192b086451882bdcac66147a5099361328 | 278d2e6af6abd933dd1d43ac3ae70bc306412ae1 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3457 | |||||
| 333805552 | MDExOlB1bGxSZXF1ZXN0MzMzODA1NTUy | 3459 | closed | 0 | Dataset.map | max-sixty 5635139 | <!-- Feel free to remove check-list items aren't relevant to your change --> - [x] Helps https://github.com/pydata/xarray/issues/1251 - [x] Tests added - [x] Passes `black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API This is the first step towards organizing these functions a bit better, as outlined in https://github.com/pydata/xarray/issues/1251, https://github.com/pydata/xarray/issues/1618, https://github.com/pydata/xarray/pull/2674 While this one is a fairly easy decision, others are going to be harder. Open to a more methodical up-front process before we start making changes, if we think that's necessary. | 2019-10-29T18:46:04Z | 2019-11-09T22:08:07Z | 2019-11-09T21:10:23Z | 2019-11-09T21:10:23Z | db0f13d194845b06fa82f64574d0e78d8449ddbe | 0 | 609cb5d31a0091e2913c48465d09a0adc503b74b | bb89534687ee5dac54d87c22154d3cfeb030ce21 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3459 | ||||
| 333824831 | MDExOlB1bGxSZXF1ZXN0MzMzODI0ODMx | 3460 | closed | 0 | fix test suite warnings re `drop` | max-sixty 5635139 | Some more warnings silenced | 2019-10-29T19:24:03Z | 2019-10-31T04:39:11Z | 2019-10-31T01:24:16Z | 2019-10-31T01:24:16Z | 96cc2bc62b33801e189dd954c6e2f335db745b66 | 0 | e772948c22b5d1f9080ef3a3d47bd26840be3073 | 4d5237ba2d56c316cbc12b25572164afdbaef541 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3460 | ||||
| 333873823 | MDExOlB1bGxSZXF1ZXN0MzMzODczODIz | 3462 | closed | 0 | Whatsnew cleanup | max-sixty 5635139 | Couple of small changes for https://github.com/pydata/xarray/issues/3434 | 2019-10-29T21:03:27Z | 2019-10-29T21:40:18Z | 2019-10-29T21:36:36Z | 2019-10-29T21:36:35Z | 11049f568e09c9f0c56c9fb453d9ae9089f5fa5b | 0 | e1363c8f6358925d4813b2b6e9d39618b3ef9252 | 4d5237ba2d56c316cbc12b25572164afdbaef541 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3462 | ||||
| 334370740 | MDExOlB1bGxSZXF1ZXN0MzM0MzcwNzQw | 3471 | closed | 0 | Restrict pytest to 'unit' tests (i.e. not hypothesis) | max-sixty 5635139 | Currently Azure is running hypothesis tests in any test job that has hypothesis installed (found in https://github.com/pydata/xarray/pull/3285). This isn't required, since we have a separate job for hypothesis, and slows down the normal tests. We can either exclude it in the test job or in the tests that pytest runs as specified in `setup.cfg` I think adjusting pytest's test paths in `setup.cfg` is a more logical place: pytest is responsible for running normal / unit tests in `xarray/tests`, and hypothesis can run the tests in `properties` | 2019-10-30T16:25:31Z | 2019-10-31T14:29:09Z | 2019-10-31T13:42:44Z | a570e878fdb1f3f9302175ea4f71cc092032e156 | 0 | 9a9f3d9024ab7c577be24547f78ee87f526382bf | 59f88f776f290f216531d074b6e73a50a9f7c37c | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3471 | |||||
| 334619816 | MDExOlB1bGxSZXF1ZXN0MzM0NjE5ODE2 | 3472 | closed | 0 | Type check sentinel values | max-sixty 5635139 | <!-- Feel free to remove check-list items aren't relevant to your change --> - [ ] Closes #xxxx - [ ] Passes `black . && mypy . && flake8` - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API I did this before I realized it only works on mypy master! But posting so no one else does it. We can wait to merge until the next version of mypy is out | 2019-10-31T02:15:57Z | 2021-04-19T06:10:36Z | 2019-10-31T15:52:02Z | 2019-10-31T15:52:02Z | 8fbe1f8409a0c0e4ce88a0c30bfc668b16c6903c | 0 | 92edcbb1841503855b37545c753d91f9c56eabcc | 96cc2bc62b33801e189dd954c6e2f335db745b66 | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3472 | ||||
| 335085538 | MDExOlB1bGxSZXF1ZXN0MzM1MDg1NTM4 | 3475 | closed | 0 | drop_vars; deprecate drop for variables | max-sixty 5635139 | <!-- Feel free to remove check-list items aren't relevant to your change --> Introduces `drop_vars`, and deprecates using `drop` for variables. `drop` is widely used for the deprecated case, so this is a fairly wide blast radius. It's more churn than is ideal, but I do think it's a much better API. This is ready for review, though I'm sure I'm missed references in the docs etc (took my peak regex skills to find/replace only the deprecated usages!) Originally discussed [here](https://github.com/pydata/xarray/pull/3460) - [x] Tests added - [x] Passes `black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API | 2019-10-31T18:46:48Z | 2019-11-07T23:20:40Z | 2019-11-07T20:13:51Z | 2019-11-07T20:13:51Z | 0e8debfe28286b5fe1f3d27e8dcc8466a62aca6d | 0 | db4b2a39cb252706dbfcfa7bd235468aaadaaec2 | 4dce93f134e8296ea730104b46ce3372b90304ac | MEMBER | xarray 13221727 | https://github.com/pydata/xarray/pull/3475 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [pull_requests] (
[id] INTEGER PRIMARY KEY,
[node_id] TEXT,
[number] INTEGER,
[state] TEXT,
[locked] INTEGER,
[title] TEXT,
[user] INTEGER REFERENCES [users]([id]),
[body] TEXT,
[created_at] TEXT,
[updated_at] TEXT,
[closed_at] TEXT,
[merged_at] TEXT,
[merge_commit_sha] TEXT,
[assignee] INTEGER REFERENCES [users]([id]),
[milestone] INTEGER REFERENCES [milestones]([id]),
[draft] INTEGER,
[head] TEXT,
[base] TEXT,
[author_association] TEXT,
[auto_merge] TEXT,
[repo] INTEGER REFERENCES [repos]([id]),
[url] TEXT,
[merged_by] INTEGER REFERENCES [users]([id])
);
CREATE INDEX [idx_pull_requests_merged_by]
ON [pull_requests] ([merged_by]);
CREATE INDEX [idx_pull_requests_repo]
ON [pull_requests] ([repo]);
CREATE INDEX [idx_pull_requests_milestone]
ON [pull_requests] ([milestone]);
CREATE INDEX [idx_pull_requests_assignee]
ON [pull_requests] ([assignee]);
CREATE INDEX [idx_pull_requests_user]
ON [pull_requests] ([user]);