issues

Another attempt at getting the docs to build again on RTD (#3182).

The current failure is due to high memory usage in the dask examples. I've converted the two most memory expensive code blocks into :verbatim: blocks so they don't use any additional memory. The contents of these blocks were taken from the last time the docs successfully built on RTD

This is hopefully a fix for #3182 but I wasn't sure how to really test this on read the docs (RTD) itself.

There may be a few things going on: * Local testing showed removing the "auto_gallery" dir would cause the failing gallery examples to actually be recognized as failing (i.e. bust the cache) * https://github.com/conda-forge/rasterio-feedstock/issues/118 and some examining of the conda list output on RTD for led me to think this was a deeper problem. Local testing with a bumped version of rasterio resulted in conda-forge being the channel source (rather than pip?), it also fixed the failing builds which relied on rasterio.

Enables the napoleon extension in sphinx. This will interpret the numpydoc style parameters and types and convert them to sphinx :param type name: Note that sphinx.ext.napoleon must come before the numpydoc extension.

Eventually the numpydoc dependency might be able to be removed but currently removing it makes the wrapped ufunc documentation omit the "parameters" and "returns", see the attached screenshot for what one of these ufuncs looks like with numpydoc removed.

• [ ] Closes #3056

This PR removes all the type hints from method signatures generated by sphinx.ext.autodoc. See http://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_typehints

The sphinx documentation doesn't say which version this was added in, but I imagine it is quite recent.

• [ ] Closes #3178

Seems I left off a trailing > in the whats-new.rst. Here is a minor fix for that.

Here is my fix for #2315 which matches the behavior of Dataset.filter_by_attrs to be that of its netCDF4 inspiration. I followed the pattern seen in the netCDF4 library which set a boolean flag while looping over attributes and short circuits the loop if any test returns false. Only if all the key=value/callable tests pass is the variable added to the output.

• [x] Closes #2315
• [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)

When using the filter_by_attrs() method of a Dataset it was returning more matches than I expected. The returned match set appears to be the logical OR of all the key=value pairs passed into the method. This does not match the behavior of the netCDF4.Dataset.get_variables_by_attributes which returns the logical AND of all the key=value pairs passed into it. I couldn't tell from the documentation if this was the intended behavior.

Minimal Example

python import xarray as xr example_dataset = xr.Dataset({ "var1": xr.DataArray([], attrs={"standard_name": "example1", "priority": 0}), "var2": xr.DataArray([], attrs={"standard_name": "example2"}) }) example_dataset.filter_by_attrs(standard_name="example2", priority=0)

Example Output

python <xarray.Dataset> Dimensions: (dim_0: 0) Dimensions without coordinates: dim_0 Data variables: var1 (dim_0) float64 var2 (dim_0) float64

Expected Output

python <xarray.Dataset> Dimensions: () Data variables: *empty*

Alternatively, chaining calls to filter_by_attrs will result in the expected behavior: ```python import xarray as xr example_dataset = xr.Dataset({ "var1": xr.DataArray([], attrs={"standard_name": "example1", "priority": 0}), "var2": xr.DataArray([], attrs={"standard_name": "example2"}) }) example_dataset.filter_by_attrs(standard_name="example2").filter_by_attrs(priority=0)

<xarray.Dataset> Dimensions: () Data variables: empty ```

Output of xr.show_versions()