Unit Test Results

6 files  ±0           6 suites  ±0   56m 27s :stopwatch: ±0s 16 228 tests ±0  14 493 :heavy_check_mark: ±0  1 735 :zzz: ±0  0 :x: ±0  90 564 runs  ±0  82 384 :heavy_check_mark: ±0  8 180 :zzz: ±0  0 :x: ±0 

Results for commit ebfc6a3d. ± Comparison against base commit ebfc6a3d.

:recycle: This comment has been updated with latest results.

The what's new entry for this went in under the wrong edition - I fixed it in https://github.com/pydata/xarray/commit/ebfc6a3db0580cc11418e906766805ff4bf36455

Thanks for the reminder @dcherian - I merged main and all the tests pass so I'll merge this PR now!

Hello @TomNicholas! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers:

Comment last updated at 2021-09-29 17:13:58 UTC

Doctests passed! Thanks so much @Illviljan !

I don't understand why doctests doesn't go through the if path, is it using tricks that can make around.__doc__ == None?

Anyway I think just ignoring these typing errors might be easier.

Readthedocs error: ```

/home/docs/checkouts/readthedocs.org/user_builds/xray/checkouts/5571/xarray/core/_typed_ops.py:docstring of xarray.core._typed_ops.DataArrayOpsMixin.round:65: WARNING: Explicit markup ends without a blank line; unexpected unindent. /home/docs/checkouts/readthedocs.org/user_builds/xray/checkouts/5571/xarray/core/_typed_ops.py:docstring of xarray.core._typed_ops.DataArrayOpsMixin.round:65: WARNING: Unexpected section title or transition. ```

I must say it gets kind of annoying having so pedantic doctests and doc generation when upstream modules aren't as picky.

Thanks @Illviljan

Seems to be a problem in numpy np.around fails the doctest, see https://github.com/numpy/numpy/issues/19759.

I wonder if the docstring can be ignored if it is copied from somewhere else?

I think an easy workaround is simply replacing the docstring: https://github.com/pydata/xarray/blob/4fd81b51101aceaad08570f1368ad4b50a946da5/xarray/core/duck_array_ops.py#L75

Saw dask does similar fixes too: https://github.com/dask/dask/blob/85f0b14bd36a5135ce51aeee067b6207374b00c4/dask/array/wrap.py#L183

Here's a version inspired by that one: ```python around = _dask_or_eager_func("around")

np.around has failing doctests, overwrite it so they pass:

https://github.com/numpy/numpy/issues/19759

around.doc = test.doc.replace( "array([0., 2.])", "array([0., 2.])", ) around.doc = test.doc.replace( "array([0.4, 1.6])", "array([0.4, 1.6])", ) around.doc = test.doc.replace( "array([0., 2., 2., 4., 4.])", "array([0., 2., 2., 4., 4.])", ) ```

```python __ [doctest] xarray.core.typed_ops.DataArrayOpsMixin.round ___ EXAMPLE LOCATION UNKNOWN, not showing all tests of that example ??? >>> np.around([0.37, 1.64]) Expected: array([0., 2.]) Got: array([0., 2.])

/home/runner/work/xarray/xarray/xarray/core/_typed_ops.py:None: DocTestFailure ``` The expected had 2 spaces after the comma for some reason. I think the actual output makes more sense now so I think it's fine to just accept this difference and change the expected output.

I think you just need to fix the spaces in the expected output

@Illviljan that actually solved those padding errors! Awesome!

The tests still fail because of something going on with np.around in the doctests though :confused:

@TomNicholas try merging main now. Let's see if there are any errors left.

The issue mentioned in dask_array_compat.pad was closed around may 2020 (https://github.com/dask/dask/pull/6213). The min version of dask can be bumped to 2.24 tomorrow (from 2.15 and 2.9), maybe that's enough to fix the errors?

for padding fail with output that is 0.5 away from what's expected

We work around some dask bugs with dask_array_compat.pad I think you'll need to revert to that and not use np.pad until we can bump dask.

EDIT: though I don't see this kind of thing being fixed there.

Now there is one more mystery: why do some of the tests for padding fail with output that is 0.5 away from what's expected??:

``` ___ TestVariableWithDask.test_pad[xr_arg3-np_arg3-mean] ______ [gw3] linux -- Python 3.7.10 /usr/share/miniconda/envs/xarray-tests/bin/python

self = <xarray.tests.test_variable.TestVariableWithDask object at 0x7f10bd848990> mode = 'mean', xr_arg = {'x': (3, 1), 'z': (2, 0)} np_arg = ((3, 1), (0, 0), (2, 0))

@pytest.mark.parametrize(
    "mode",
    [
        "mean",
        pytest.param(
            "median",
            marks=pytest.mark.xfail(reason="median is not implemented by Dask"),
        ),
        pytest.param(
            "reflect", marks=pytest.mark.xfail(reason="dask.array.pad bug")
        ),
        "edge",
        pytest.param(
            "linear_ramp",
            marks=pytest.mark.xfail(
                reason="pint bug: https://github.com/hgrecco/pint/issues/1026"
            ),
        ),
        "maximum",
        "minimum",
        "symmetric",
        "wrap",
    ],
)
@pytest.mark.parametrize("xr_arg, np_arg", _PAD_XR_NP_ARGS)
@pytest.mark.filterwarnings(
    r"ignore:dask.array.pad.+? converts integers to floats."
)
def test_pad(self, mode, xr_arg, np_arg):
    data = np.arange(4 * 3 * 2).reshape(4, 3, 2)
    v = self.cls(["x", "y", "z"], data)

    actual = v.pad(mode=mode, **xr_arg)
    expected = np.pad(data, np_arg, mode=mode)

  assert_array_equal(actual, expected)

E AssertionError: E Arrays are not equal E
E Mismatched elements: 48 / 96 (50%) E Max absolute difference: 0.5 E Max relative difference: 0.25 E x: array([[[ 9.5, 9.5, 9. , 10. ], E [11.5, 11.5, 11. , 12. ], E [13.5, 13.5, 13. , 14. ]],... E y: array([[[10, 10, 9, 10], E [12, 12, 11, 12], E [14, 14, 13, 14]],... ```

Looks great! I don't know the details of this code well, but at the conceptual level it looks good!

A net-negative pull request 🤯

The best type!

A net-negative pull request :exploding_head:

Right I understand the failure now - everywhere where _dask_or_eager_func was dispatching numpy->dask is working fine via NEP-18, but my change made pandas.isnull no longer dispatch to dask.isnull, which then computes (and raises because we want it to be lazy). The solution is to special-case that one use of pandas (and perhaps any other uses of pandas?).