Question: Calling () drops coordinates This is a similar issue to bug . <!-- In order for the maintainers to efficiently understand and prioritize issues, we ask you post a "Minimal, Complete and Verifiable Example" (MCVE): --Output (with extra stuff snipped for brevity): It's also worth mentioning that the data arrays contained in the dataset also loose their coordinates during this operation. I.E: <detailsINSTALLED VERSIONS commit: None python: 3.7.4 (tags/v3.7.4:, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 machine: AMD64 processor: Intel64 Family 6 Model 158 Stepping 11, GenuineIntel byteorder: little LCALL: None LANG: None LOCALE: None.None libhdf5: 1.10.5 libnetcdf: 4.7.2 xarray: 0.14.0 pandas: 0.25.2 numpy: 1.17.3 scipy: 1.3.1 netCDF4: 1.5.3 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.0.4.2 nctime_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: 2.7.0 distributed: None matplotlib: 3.1.1 cartopy: None seaborn: None numbagg: None setuptools: 40.8.0 pip: 19.3 conda: None pytest: None IPython: 7.8.0 sphinx: None None </details

See Also         --------         DataArray.argmin         """        if dim is None and axis is None:        if dim is None:             warnings.warn(                "Once the behaviour of DataArray.argmin() and Variable.argmin() with "                "neither dim nor axis argument changes to return a dict of indices of "                "each dimension, for consistency it will be an error to call "                "Dataset.argmin() with no argument, since we don't return a dict of "                "Datasets.",                "Once the behaviour of DataArray.argmin() and Variable.argmin() without "                "dim changes to return a dict of indices of each dimension, for "                "consistency it will be an error to call Dataset.argmin() with no argument,"                "since we don't return a dict of Datasets.",                 DeprecationWarning,                 stacklevel=2,             )         if (             dim is None            or axis is not None             or (not isinstance(dim, Sequence) and dim is not ...)             or isinstance(dim, str)         ):             # Return int index if single dimension is passed, and is not part of a             # sequence             argmin_func = getattr(duck_array_ops, "argmin")            return self.reduce(argmin_func, dim=dim, axis=axis, **kwargs)            return self.reduce(argmin_func, dim=dim, **kwargs)         else:             raise ValueError(                 "When dim is a sequence or ..., DataArray.argmin() returns a dict. "


Question: Calling () drops coordinates This is a similar issue to bug . <!-- In order for the maintainers to efficiently understand and prioritize issues, we ask you post a "Minimal, Complete and Verifiable Example" (MCVE): --Output (with extra stuff snipped for brevity): It's also worth mentioning that the data arrays contained in the dataset also loose their coordinates during this operation. I.E: <detailsINSTALLED VERSIONS commit: None python: 3.7.4 (tags/v3.7.4:, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 machine: AMD64 processor: Intel64 Family 6 Model 158 Stepping 11, GenuineIntel byteorder: little LCALL: None LANG: None LOCALE: None.None libhdf5: 1.10.5 libnetcdf: 4.7.2 xarray: 0.14.0 pandas: 0.25.2 numpy: 1.17.3 scipy: 1.3.1 netCDF4: 1.5.3 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.0.4.2 nctime_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: 2.7.0 distributed: None matplotlib: 3.1.1 cartopy: None seaborn: None numbagg: None setuptools: 40.8.0 pip: 19.3 conda: None pytest: None IPython: 7.8.0 sphinx: None None </details

"Dataset.argmin() with a sequence or ... for dim"             )     def argmax(self, dim=None, axis=None, **kwargs):    def argmax(self, dim=None, **kwargs):         """Indices of the maxima of the member variables.          If there are multiple maxima, the indices of the first one found will be


Question: Calling () drops coordinates This is a similar issue to bug . <!-- In order for the maintainers to efficiently understand and prioritize issues, we ask you post a "Minimal, Complete and Verifiable Example" (MCVE): --Output (with extra stuff snipped for brevity): It's also worth mentioning that the data arrays contained in the dataset also loose their coordinates during this operation. I.E: <detailsINSTALLED VERSIONS commit: None python: 3.7.4 (tags/v3.7.4:, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 machine: AMD64 processor: Intel64 Family 6 Model 158 Stepping 11, GenuineIntel byteorder: little LCALL: None LANG: None LOCALE: None.None libhdf5: 1.10.5 libnetcdf: 4.7.2 xarray: 0.14.0 pandas: 0.25.2 numpy: 1.17.3 scipy: 1.3.1 netCDF4: 1.5.3 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.0.4.2 nctime_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: 2.7.0 distributed: None matplotlib: 3.1.1 cartopy: None seaborn: None numbagg: None setuptools: 40.8.0 pip: 19.3 conda: None pytest: None IPython: 7.8.0 sphinx: None None </details

this is deprecated, in future will be an error, since DataArray.argmax will             return a dict with indices for all dimensions, which does not make sense for             a Dataset.<del>        axis : int, optional            Axis over which to apply `argmax`. Only one of the 'dim' and 'axis' arguments            can be supplied.</del>         keep_attrs : bool, optional             If True, the attributes (`attrs`) will be copied from the original             object to the new one.  If False (default), the new object will be


Question: Calling () drops coordinates This is a similar issue to bug . <!-- In order for the maintainers to efficiently understand and prioritize issues, we ask you post a "Minimal, Complete and Verifiable Example" (MCVE): --Output (with extra stuff snipped for brevity): It's also worth mentioning that the data arrays contained in the dataset also loose their coordinates during this operation. I.E: <detailsINSTALLED VERSIONS commit: None python: 3.7.4 (tags/v3.7.4:, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 machine: AMD64 processor: Intel64 Family 6 Model 158 Stepping 11, GenuineIntel byteorder: little LCALL: None LANG: None LOCALE: None.None libhdf5: 1.10.5 libnetcdf: 4.7.2 xarray: 0.14.0 pandas: 0.25.2 numpy: 1.17.3 scipy: 1.3.1 netCDF4: 1.5.3 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.0.4.2 nctime_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: 2.7.0 distributed: None matplotlib: 3.1.1 cartopy: None seaborn: None numbagg: None setuptools: 40.8.0 pip: 19.3 conda: None pytest: None IPython: 7.8.0 sphinx: None None </details

DataArray.argmax          """        if dim is None and axis is None:        if dim is None:             warnings.warn(                "Once the behaviour of DataArray.argmax() and Variable.argmax() with "                "neither dim nor axis argument changes to return a dict of indices of "                "each dimension, for consistency it will be an error to call "                "Dataset.argmax() with no argument, since we don't return a dict of "                "Datasets.",                "Once the behaviour of DataArray.argmin() and Variable.argmin() without "                "dim changes to return a dict of indices of each dimension, for "                "consistency it will be an error to call Dataset.argmin() with no argument,"                "since we don't return a dict of Datasets.",                 DeprecationWarning,                 stacklevel=2,             )         if (             dim is None            or axis is not None             or (not isinstance(dim, Sequence) and dim is not ...)             or isinstance(dim, str)         ):             # Return int index if single dimension is passed, and is not part of a             # sequence             argmax_func = getattr(duck_array_ops, "argmax")            return self.reduce(argmax_func, dim=dim, axis=axis, **kwargs)            return self.reduce(argmax_func, dim=dim, **kwargs)         else:             raise ValueError(                 "When dim is a sequence or ..., DataArray.argmin() returns a dict. "


Question: Handling of signed bytes from OPeNDAP via pydap netCDF3 only knows signed bytes, but there's of adding an attribute to the variable to be able to store unsigned bytes non the less. This convention is handled by xarray. OPeNDAP only knows unsigned bytes, but there's which is used by the thredds server and the netCDF-c library of adding an attribute to the variable to be able to store signed bytes non the less. This hack is not handled by xarray, but maybe should be handled symmetrically at the same place (i.e. ). As descibed in the "hack", netCDF-c handles this internally, but pydap doesn't. This is why the variant returns (correctly according to the hack) negative values and the variant doesn't. However, as returns a warning at exactly the location referenced above, I think that this is the place where it should be fixed. If you agree, I could prepare a PR to implement the fix. Handling of signed bytes from OPeNDAP via pydap netCDF3 only knows signed bytes, but there's of adding an attribute to the variable to be able to store unsigned bytes non the less. This convention is handled by xarray. OPeNDAP only knows unsigned bytes, but there's which is used by the thredds server and the netCDF-c library of adding an attribute to the variable to be able to store signed bytes non the less. This hack is not handled by xarray, but maybe should be handled symmetrically at the same place (i.e. ). As descibed in the "hack", netCDF-c handles this internally, but pydap doesn't. This is why the variant returns (correctly according to the hack) negative values and the variant doesn't. However, as returns a warning at exactly the location referenced above, I think that this is the place where it should be fixed. If you agree, I could prepare a PR to implement the fix.

if "_FillValue" in attrs:                         new_fill = unsigned_dtype.type(attrs["_FillValue"])                         attrs["_FillValue"] = new_fill<ins>            elif data.dtype.kind == "u":                if unsigned == "false":                    signed_dtype = np.dtype("i%s" % data.dtype.itemsize)                    transform = partial(np.asarray, dtype=signed_dtype)                    data = lazy_elemwise_func(data, transform, signed_dtype)                    if "_FillValue" in attrs:                        new_fill = signed_dtype.type(attrs["_FillValue"])                        attrs["_FillValue"] = new_fill</ins>             else:                 warnings.warn(                     "variable %r has _Unsigned attribute but is not "


Question: Date missing in datetime accessor What happened: I wonder if there is a reason, why there is no attribute in the datetime accessor. What you expected to happen: As the attribute is supported I would expect the same for the attribute Minimal Complete Verifiable Example: Suggestion: A simple addition of in should do the trick. Happy to do a PR. Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.6 (default, Oct 7 2020, 19:08:05) [GCC 7.5.0] python-bits: 64 OS: Linux OS-release: 2.6.32-754.33.1.el6.x8664 machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enUS.UTF-8 LOCALE: enUS.UTF-8 libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.17.0 pandas: 1.2.1 numpy: 1.20.0 scipy: 1.6.0 netCDF4: 1.5.5.1 pydap: None h5netcdf: None h5py: None Nio: None zarr: 2.6.1 cftime: 1.4.1 nctime_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: 2021.02.0 distributed: 2021.02.0 matplotlib: 3.3.4 cartopy: 0.18.0 seaborn: 0.11.1 numbagg: None pint: 0.16.1 setuptools: 49.6.0.post20210108 pip: 21.0.1 conda: None pytest: None IPython: 7.20.0 sphinx: None </details

if name == "season":         months = values_as_cftimeindex.month         field_values = _season_from_months(months)<ins>    elif name == "date":        raise AttributeError(            "'CFTimeIndex' object has no attribute `date`. Consider using the floor method instead, for instance: `.time.dt.floor('D')`."        )</ins>     else:         field_values = getattr(values_as_cftimeindex, name)     return field_values.reshape(values.shape)


Question: Date missing in datetime accessor What happened: I wonder if there is a reason, why there is no attribute in the datetime accessor. What you expected to happen: As the attribute is supported I would expect the same for the attribute Minimal Complete Verifiable Example: Suggestion: A simple addition of in should do the trick. Happy to do a PR. Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.6 (default, Oct 7 2020, 19:08:05) [GCC 7.5.0] python-bits: 64 OS: Linux OS-release: 2.6.32-754.33.1.el6.x8664 machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enUS.UTF-8 LOCALE: enUS.UTF-8 libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.17.0 pandas: 1.2.1 numpy: 1.20.0 scipy: 1.6.0 netCDF4: 1.5.5.1 pydap: None h5netcdf: None h5py: None Nio: None zarr: 2.6.1 cftime: 1.4.1 nctime_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: 2021.02.0 distributed: 2021.02.0 matplotlib: 3.3.4 cartopy: 0.18.0 seaborn: 0.11.1 numbagg: None pint: 0.16.1 setuptools: 49.6.0.post20210108 pip: 21.0.1 conda: None pytest: None IPython: 7.20.0 sphinx: None </details

"time", "Timestamps corresponding to datetimes", object     ) <ins>    date = Properties._tslib_field_accessor(        "date", "Date corresponding to datetimes", object    )</ins>     is_month_start = Properties._tslib_field_accessor(         "is_month_start",         "Indicates whether the date is the first day of the month.",


Question: Simplify adding custom backends <!-- Please do a quick search of existing issues to make sure that this has not been asked before. --Is your feature request related to a problem? Please describe. I've been working on opening custom hdf formats in xarray, reading up on the apiv2 it is currently only possible to declare a new external plugin in but that doesn't seem easy or intuitive to me. Describe the solution you'd like Why can't we simply be allowed to add functions to the engine parameter? Example: This seems like a small function change to me from my initial quick look because there's mainly a bunch of string checks in the normal case until we get to the registered backend functions, if we send in a function instead in the engine-parameter we can just bypass those checks.

scipy.io.netcdf (only netCDF3 supported). Byte-strings or file-like         objects are opened by scipy.io.netcdf (netCDF3) or h5py (netCDF4/HDF).     engine : {"netcdf4", "scipy", "pydap", "h5netcdf", "pynio", "cfgrib", \        "pseudonetcdf", "zarr"}, optional        "pseudonetcdf", "zarr"} or subclass of xarray.backends.BackendEntrypoint, optional         Engine to use when reading files. If not provided, the default engine         is chosen based on available dependencies, with a preference for        "netcdf4".        "netcdf4". A custom backend class (a subclass of ``BackendEntrypoint``)        can also be used.     chunks : int or dict, optional         If chunks is provided, it is used to load the new dataset into dask         arrays. ``chunks=-1`` loads the dataset with dask using a singlediff --git a/xarray/backends/plugins.py b/xarray/backends/plugins.py-- a/xarray/backends/plugins.py++ b/xarray/backends/plugins.py


Question: Simplify adding custom backends <!-- Please do a quick search of existing issues to make sure that this has not been asked before. --Is your feature request related to a problem? Please describe. I've been working on opening custom hdf formats in xarray, reading up on the apiv2 it is currently only possible to declare a new external plugin in but that doesn't seem easy or intuitive to me. Describe the solution you'd like Why can't we simply be allowed to add functions to the engine parameter? Example: This seems like a small function change to me from my initial quick look because there's mainly a bunch of string checks in the normal case until we get to the registered backend functions, if we send in a function instead in the engine-parameter we can just bypass those checks.

import pkg_resources from .common import BACKEND_ENTRYPOINTSfrom .common import BACKEND_ENTRYPOINTS, BackendEntrypoint  STANDARD_BACKENDS_ORDER = ["netcdf4", "h5netcdf", "scipy"]


Question: Simplify adding custom backends <!-- Please do a quick search of existing issues to make sure that this has not been asked before. --Is your feature request related to a problem? Please describe. I've been working on opening custom hdf formats in xarray, reading up on the apiv2 it is currently only possible to declare a new external plugin in but that doesn't seem easy or intuitive to me. Describe the solution you'd like Why can't we simply be allowed to add functions to the engine parameter? Example: This seems like a small function change to me from my initial quick look because there's mainly a bunch of string checks in the normal case until we get to the registered backend functions, if we send in a function instead in the engine-parameter we can just bypass those checks.

def get_backend(engine):    """Select open_dataset method based on current engine"""    engines = list_engines()    if engine not in engines:        raise ValueError(            f"unrecognized engine {engine} must be one of: {list(engines)}"    """Select open_dataset method based on current engine."""    if isinstance(engine, str):        engines = list_engines()        if engine not in engines:            raise ValueError(                f"unrecognized engine {engine} must be one of: {list(engines)}"            )        backend = engines[engine]    elif isinstance(engine, type) and issubclass(engine, BackendEntrypoint):        backend = engine    else:        raise TypeError(            (                "engine must be a string or a subclass of "                f"xarray.backends.BackendEntrypoint: {engine}"            )         )    return engines[engine]    return backend


Question: Trailing whitespace in DatasetGroupBy text representation When displaying a DatasetGroupBy in an interactive Python session, the first line of output contains a trailing whitespace. The first example in the documentation demonstrate this: There is a trailing whitespace in the first line of output which is "DatasetGroupBy, grouped over 'letters' ". This can be seen more clearly by converting the object to a string (note the whitespace before ): While this isn't a problem in itself, it causes an issue for us because we use flake8 in continuous integration to verify that our code is correctly formatted and we also have doctests that rely on DatasetGroupBy textual representation. Flake8 reports a violation on the trailing whitespaces in our docstrings. If we remove the trailing whitespaces, our doctests fail because the expected output doesn't match the actual output. So we have conflicting constraints coming from our tools which both seem reasonable. Trailing whitespaces are forbidden by flake8 because, among other reasons, they lead to noisy git diffs. Doctest want the expected output to be exactly the same as the actual output and considers a trailing whitespace to be a significant difference. We could configure flake8 to ignore this particular violation for the files in which we have these doctests, but this may cause other trailing whitespaces to creep in our code, which we don't want. Unfortunately it's not possible to just add comments to get flake8 to ignore the violation only for specific lines because that creates a difference between expected and actual output from doctest point of view. Flake8 doesn't allow to disable checks for blocks of code either. Is there a reason for having this trailing whitespace in DatasetGroupBy representation? Whould it be OK to remove it? If so please let me know and I can make a pull request.

return zip(self._unique_coord.values, self._iter_grouped())      def __repr__(self):        return "{}, grouped over {!r} \n{!r} groups with labels {}.".format(        return "{}, grouped over {!r}\n{!r} groups with labels {}.".format(             self.__class__.__name__,             self._unique_coord.name,             self._unique_coord.size,


Question: opendataset uses cftime, not datetime64, when calendar attribute is "Gregorian" <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: I used to open a NetCDF file whose coordinate had the attribute set to . All dates were within the Timestamp-valid range. The resulting dataset represented the co-ordinate as a . What you expected to happen: I expected the dataset to represent the co-ordinate as a , as documented and . Minimal Complete Verifiable Example: Anything else we need to know?: The says: In practice, we are getting some s even for times which are interpretable and representable as s. In particular, we have some NetCDF files in which the variable has a attribute with a value of (with a capital ‘G’). CF conventions : However, xarray regards as a non-standard calendar and falls back to . If (as in the example) is to , the times are read as s. Suggested fix: in , change ‘’ to ‘’. Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.9.2 (default, Feb 21 2021, 05:02:46) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 5.8.0-48-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enGB.UTF-8 LOCALE: enGB.UTF-8 libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.17.1.dev39+g45b4436b pandas: 1.2.3 numpy: 1.20.2 scipy: None netCDF4: 1.5.6 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.4.1 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: None distributed: None matplotlib: None cartopy: None seaborn: None numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.0.1 conda: None pytest: None IPython: None sphinx: None <!-- Paste the output here xr.show_versions() here --</details

)  <ins>def _is_standard_calendar(calendar):    return calendar.lower() in _STANDARD_CALENDARS</ins> def _netcdf_to_numpy_timeunit(units):     units = units.lower()     if not units.endswith("s"):


Question: opendataset uses cftime, not datetime64, when calendar attribute is "Gregorian" <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: I used to open a NetCDF file whose coordinate had the attribute set to . All dates were within the Timestamp-valid range. The resulting dataset represented the co-ordinate as a . What you expected to happen: I expected the dataset to represent the co-ordinate as a , as documented and . Minimal Complete Verifiable Example: Anything else we need to know?: The says: In practice, we are getting some s even for times which are interpretable and representable as s. In particular, we have some NetCDF files in which the variable has a attribute with a value of (with a capital ‘G’). CF conventions : However, xarray regards as a non-standard calendar and falls back to . If (as in the example) is to , the times are read as s. Suggested fix: in , change ‘’ to ‘’. Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.9.2 (default, Feb 21 2021, 05:02:46) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 5.8.0-48-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enGB.UTF-8 LOCALE: enGB.UTF-8 libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.17.1.dev39+g45b4436b pandas: 1.2.3 numpy: 1.20.2 scipy: None netCDF4: 1.5.6 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.4.1 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: None distributed: None matplotlib: None cartopy: None seaborn: None numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.0.1 conda: None pytest: None IPython: None sphinx: None <!-- Paste the output here xr.show_versions() here --</details

def _decode_datetime_with_pandas(flat_num_dates, units, calendar):    if calendar not in _STANDARD_CALENDARS:    if not _is_standard_calendar(calendar):         raise OutOfBoundsDatetime(             "Cannot decode times from a non-standard calendar, {!r}, using "             "pandas.".format(calendar)


Question: opendataset uses cftime, not datetime64, when calendar attribute is "Gregorian" <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: I used to open a NetCDF file whose coordinate had the attribute set to . All dates were within the Timestamp-valid range. The resulting dataset represented the co-ordinate as a . What you expected to happen: I expected the dataset to represent the co-ordinate as a , as documented and . Minimal Complete Verifiable Example: Anything else we need to know?: The says: In practice, we are getting some s even for times which are interpretable and representable as s. In particular, we have some NetCDF files in which the variable has a attribute with a value of (with a capital ‘G’). CF conventions : However, xarray regards as a non-standard calendar and falls back to . If (as in the example) is to , the times are read as s. Suggested fix: in , change ‘’ to ‘’. Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.9.2 (default, Feb 21 2021, 05:02:46) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 5.8.0-48-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enGB.UTF-8 LOCALE: enGB.UTF-8 libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.17.1.dev39+g45b4436b pandas: 1.2.3 numpy: 1.20.2 scipy: None netCDF4: 1.5.6 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.4.1 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: None distributed: None matplotlib: None cartopy: None seaborn: None numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.0.1 conda: None pytest: None IPython: None sphinx: None <!-- Paste the output here xr.show_versions() here --</details

dates[np.nanargmin(num_dates)].year < 1678                 or dates[np.nanargmax(num_dates)].year >= 2262             ):                if calendar in _STANDARD_CALENDARS:                if _is_standard_calendar(calendar):                     warnings.warn(                         "Unable to decode time axis into full "                         "numpy.datetime64 objects, continuing using "


Question: opendataset uses cftime, not datetime64, when calendar attribute is "Gregorian" <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: I used to open a NetCDF file whose coordinate had the attribute set to . All dates were within the Timestamp-valid range. The resulting dataset represented the co-ordinate as a . What you expected to happen: I expected the dataset to represent the co-ordinate as a , as documented and . Minimal Complete Verifiable Example: Anything else we need to know?: The says: In practice, we are getting some s even for times which are interpretable and representable as s. In particular, we have some NetCDF files in which the variable has a attribute with a value of (with a capital ‘G’). CF conventions : However, xarray regards as a non-standard calendar and falls back to . If (as in the example) is to , the times are read as s. Suggested fix: in , change ‘’ to ‘’. Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.9.2 (default, Feb 21 2021, 05:02:46) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 5.8.0-48-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enGB.UTF-8 LOCALE: enGB.UTF-8 libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.17.1.dev39+g45b4436b pandas: 1.2.3 numpy: 1.20.2 scipy: None netCDF4: 1.5.6 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.4.1 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: None distributed: None matplotlib: None cartopy: None seaborn: None numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.0.1 conda: None pytest: None IPython: None sphinx: None <!-- Paste the output here xr.show_versions() here --</details

stacklevel=3,                     )             else:                if calendar in _STANDARD_CALENDARS:                if _is_standard_calendar(calendar):                     dates = cftime_to_nptime(dates)     elif use_cftime:         dates = _decode_datetime_with_cftime(flat_num_dates, units, calendar)


Question: opendataset uses cftime, not datetime64, when calendar attribute is "Gregorian" <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: I used to open a NetCDF file whose coordinate had the attribute set to . All dates were within the Timestamp-valid range. The resulting dataset represented the co-ordinate as a . What you expected to happen: I expected the dataset to represent the co-ordinate as a , as documented and . Minimal Complete Verifiable Example: Anything else we need to know?: The says: In practice, we are getting some s even for times which are interpretable and representable as s. In particular, we have some NetCDF files in which the variable has a attribute with a value of (with a capital ‘G’). CF conventions : However, xarray regards as a non-standard calendar and falls back to . If (as in the example) is to , the times are read as s. Suggested fix: in , change ‘’ to ‘’. Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.9.2 (default, Feb 21 2021, 05:02:46) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 5.8.0-48-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enGB.UTF-8 LOCALE: enGB.UTF-8 libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.17.1.dev39+g45b4436b pandas: 1.2.3 numpy: 1.20.2 scipy: None netCDF4: 1.5.6 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.4.1 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: None dask: None distributed: None matplotlib: None cartopy: None seaborn: None numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.0.1 conda: None pytest: None IPython: None sphinx: None <!-- Paste the output here xr.show_versions() here --</details

delta, ref_date = _unpack_netcdf_time_units(units)     try:        if calendar not in _STANDARD_CALENDARS or dates.dtype.kind == "O":        if not _is_standard_calendar(calendar) or dates.dtype.kind == "O":             # parse with cftime instead             raise OutOfBoundsDatetime         assert dates.dtype == "datetime64[ns]"


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None

# See issue dask/dask#6516         coeffs, residuals, _, _ = da.linalg.lstsq(lhs_da, rhs)     return coeffs, residualsdef push(array, n, axis):    """    Dask-aware bottleneck.push    """    from bottleneck import push    if len(array.chunks[axis]) > 1 and n is not None and n < array.shape[axis]:        raise NotImplementedError(            "Cannot fill along a chunked axis when limit is not None."            "Either rechunk to a single chunk along this axis or call .compute() or .load() first."        )    if all(c == 1 for c in array.chunks[axis]):        array = array.rechunk({axis: 2})    pushed = array.map_blocks(push, axis=axis, n=n)    if len(array.chunks[axis]) > 1:        pushed = pushed.map_overlap(            push, axis=axis, n=n, depth={axis: (1, 0)}, boundary="none"        )    return pusheddiff --git a/xarray/core/dataarray.py b/xarray/core/dataarray.py-- a/xarray/core/dataarray.py++ b/xarray/core/dataarray.py


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None

The maximum number of consecutive NaN values to forward fill. In             other words, if there is a gap with more than this number of             consecutive NaNs, it will only be partially filled. Must be greater            than 0 or None for no limit.            than 0 or None for no limit. Must be None or greater than or equal            to axis length if filling along chunked axes (dimensions).          Returns         -------


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None

The maximum number of consecutive NaN values to backward fill. In             other words, if there is a gap with more than this number of             consecutive NaNs, it will only be partially filled. Must be greater            than 0 or None for no limit.            than 0 or None for no limit. Must be None or greater than or equal            to axis length if filling along chunked axes (dimensions).          Returns         -------diff --git a/xarray/core/dataset.py b/xarray/core/dataset.py-- a/xarray/core/dataset.py++ b/xarray/core/dataset.py


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None

The maximum number of consecutive NaN values to backward fill. In             other words, if there is a gap with more than this number of             consecutive NaNs, it will only be partially filled. Must be greater            than 0 or None for no limit.            than 0 or None for no limit. Must be None or greater than or equal            to axis length if filling along chunked axes (dimensions).          Returns         -------diff --git a/xarray/core/duck_array_ops.py b/xarray/core/duck_array_ops.py-- a/xarray/core/duck_array_ops.py++ b/xarray/core/duck_array_ops.py


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None

return dask_array_ops.least_squares(lhs, rhs, rcond=rcond, skipna=skipna)     else:         return nputils.least_squares(lhs, rhs, rcond=rcond, skipna=skipna)def push(array, n, axis):    from bottleneck import push    if is_duck_dask_array(array):        return dask_array_ops.push(array, n, axis)    else:        return push(array, n, axis)diff --git a/xarray/core/missing.py b/xarray/core/missing.py-- a/xarray/core/missing.py++ b/xarray/core/missing.py


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None

from . import utils from .common import _contains_datetime_like_objects, ones_like from .computation import apply_ufuncfrom .duck_array_ops import datetime_to_numeric, timedelta_to_numericfrom .duck_array_ops import datetime_to_numeric, push, timedelta_to_numeric from .options import _get_keep_attrs from .pycompat import is_duck_dask_array from .utils import OrderedSet, is_scalar


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None

def _bfill(arr, n=None, axis=-1):     """inverse of ffill"""    import bottleneck as bn     arr = np.flip(arr, axis=axis)      # fill    arr = bn.push(arr, axis=axis, n=n)    arr = push(arr, axis=axis, n=n)      # reverse back to original     return np.flip(arr, axis=axis)


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None

def ffill(arr, dim=None, limit=None):     """forward fill missing values"""    import bottleneck as bn     axis = arr.get_axis_num(dim)      # work around for bottleneck 178     _limit = limit if limit is not None else arr.shape[axis]      return apply_ufunc(        bn.push,        push,         arr,        dask="parallelized",        dask="allowed",         keep_attrs=True,         output_dtypes=[arr.dtype],         kwargs=dict(n=_limit, axis=axis),


Question: bfill behavior dask arrays with small chunk size bfill methods seems to miss nans when dask array chunk size is small. Resulting array still has nan present (see 'small chunk' section of code) absence of nans INSTALLED VERSIONS commit: None python: python-bits: 64 OS: Linux OS-release: 4.15.0-43-generic machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enCA.UTF-8 LOCALE: en_CA.UTF-8 xarray: 0.11.0 pandas: 0.23.4 numpy: 1.15.4 scipy: None netCDF4: None h5netcdf: None h5py: None Nio: None zarr: None cftime: None PseudonetCDF: None rasterio: None iris: None bottleneck: 1.2.1 cyordereddict: None dask: 1.0.0 distributed: 1.25.2 matplotlib: None cartopy: None seaborn: None setuptools: 40.6.3 pip: 18.1 conda: None pytest: None IPython: None sphinx: None

return apply_ufunc(         _bfill,         arr,        dask="parallelized",        dask="allowed",         keep_attrs=True,         output_dtypes=[arr.dtype],         kwargs=dict(n=_limit, axis=axis),


Question: Should weighted operations raise an error when dimensions don't exist? <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Weighted operations don't raise an error when the dimensions passed don't exist. What you expected to happen: This is not really a bug, but I find it a bit confusing because it's not consistent with the same "unweighted" operation. Minimal Complete Verifiable Example: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summary<!-- Paste the output here xr.showversions() here --INSTALLED VERSIONS commit: None python: 3.9.4 (default, May 10 2021, 22:13:33) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 3.10.0-1062.18.1.el7.x8664 machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enGB.UTF-8 LOCALE: ('enGB', 'UTF-8') libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.18.1.dev30+g2578fc3 pandas: 1.2.4 numpy: 1.20.2 scipy: 1.6.3 netCDF4: 1.5.6 pydap: installed h5netcdf: 0.11.0 h5py: 3.2.1 Nio: None zarr: 2.8.1 cftime: 1.4.1 nctimeaxis: 1.2.0 PseudoNetCDF: None rasterio: 1.2.3 cfgrib: 0.9.9.0 iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: 0.19.0.post1 seaborn: 0.11.1 numbagg: installed pint: None setuptools: 49.6.0.post20210108 pip: 21.1.1 conda: None pytest: None IPython: 7.23.1 sphinx: None </details

self.obj: T_DataWithCoords = obj         self.weights: "DataArray" = weights <ins>    def _check_dim(self, dim: Optional[Union[Hashable, Iterable[Hashable]]]):        """raise an error if any dimension is missing"""        if isinstance(dim, str) or not isinstance(dim, Iterable):            dims = [dim] if dim else []        else:            dims = list(dim)        missing_dims = set(dims) - set(self.obj.dims) - set(self.weights.dims)        if missing_dims:            raise ValueError(                f"{self.__class__.__name__} does not contain the dimensions: {missing_dims}"            )</ins>     @staticmethod     def _reduce(         da: "DataArray",


Question: Should weighted operations raise an error when dimensions don't exist? <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Weighted operations don't raise an error when the dimensions passed don't exist. What you expected to happen: This is not really a bug, but I find it a bit confusing because it's not consistent with the same "unweighted" operation. Minimal Complete Verifiable Example: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summary<!-- Paste the output here xr.showversions() here --INSTALLED VERSIONS commit: None python: 3.9.4 (default, May 10 2021, 22:13:33) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 3.10.0-1062.18.1.el7.x8664 machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enGB.UTF-8 LOCALE: ('enGB', 'UTF-8') libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.18.1.dev30+g2578fc3 pandas: 1.2.4 numpy: 1.20.2 scipy: 1.6.3 netCDF4: 1.5.6 pydap: installed h5netcdf: 0.11.0 h5py: 3.2.1 Nio: None zarr: 2.8.1 cftime: 1.4.1 nctimeaxis: 1.2.0 PseudoNetCDF: None rasterio: 1.2.3 cfgrib: 0.9.9.0 iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: 0.19.0.post1 seaborn: 0.11.1 numbagg: installed pint: None setuptools: 49.6.0.post20210108 pip: 21.1.1 conda: None pytest: None IPython: 7.23.1 sphinx: None </details

class DataArrayWeighted(Weighted["DataArray"]):     def _implementation(self, func, dim, **kwargs) -> "DataArray": <ins>        self._check_dim(dim)</ins>         dataset = self.obj._to_temp_dataset()         dataset = dataset.map(func, dim=dim, **kwargs)         return self.obj._from_temp_dataset(dataset)


Question: Should weighted operations raise an error when dimensions don't exist? <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Weighted operations don't raise an error when the dimensions passed don't exist. What you expected to happen: This is not really a bug, but I find it a bit confusing because it's not consistent with the same "unweighted" operation. Minimal Complete Verifiable Example: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summary<!-- Paste the output here xr.showversions() here --INSTALLED VERSIONS commit: None python: 3.9.4 (default, May 10 2021, 22:13:33) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 3.10.0-1062.18.1.el7.x8664 machine: x8664 processor: x8664 byteorder: little LCALL: None LANG: enGB.UTF-8 LOCALE: ('enGB', 'UTF-8') libhdf5: 1.10.6 libnetcdf: 4.7.4 xarray: 0.18.1.dev30+g2578fc3 pandas: 1.2.4 numpy: 1.20.2 scipy: 1.6.3 netCDF4: 1.5.6 pydap: installed h5netcdf: 0.11.0 h5py: 3.2.1 Nio: None zarr: 2.8.1 cftime: 1.4.1 nctimeaxis: 1.2.0 PseudoNetCDF: None rasterio: 1.2.3 cfgrib: 0.9.9.0 iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: 0.19.0.post1 seaborn: 0.11.1 numbagg: installed pint: None setuptools: 49.6.0.post20210108 pip: 21.1.1 conda: None pytest: None IPython: 7.23.1 sphinx: None </details

class DatasetWeighted(Weighted["Dataset"]):     def _implementation(self, func, dim, **kwargs) -> "Dataset": <ins>        self._check_dim(dim)</ins>         return self.obj.map(func, dim=dim, **kwargs)


Question: Feature request: vector cross product xarray currently has the function for calculating arbitrary dot products which is indeed very handy. Sometimes, especially for physical applications I also need a vector cross product. I' wondering whether you would be interested in having as a wrapper of I currently use the following implementation: Do you want such a function (and possibly associated methods) in the namespace, or should it be in some other package? I didn't find a package which would be a good fit as this is close to core numpy functionality and isn't as domain specific as some geo packages. I'm not aware of some "xrphysics" package. I could make a PR if you'd want to have it in directly. <detailsINSTALLED VERSIONS commit: None python: 3.7.3 (default, Mar 27 2019, 22:11:17) [GCC 7.3.0] python-bits: 64 OS: Linux OS-release: 4.9.0-9-amd64 machine: x8664 processor: byteorder: little LCALL: None LANG: enUS.UTF-8 LOCALE: enUS.UTF-8 libhdf5: 1.10.4 libnetcdf: 4.6.1 xarray: 0.12.3 pandas: 0.24.2 numpy: 1.16.4 scipy: 1.3.0 netCDF4: 1.4.2 pydap: None h5netcdf: 0.7.4 h5py: 2.9.0 Nio: None zarr: None cftime: 1.0.3.4 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.2.1 dask: 2.1.0 distributed: 2.1.0 matplotlib: 3.1.0 cartopy: None seaborn: 0.9.0 numbagg: None setuptools: 41.0.1 pip: 19.1.1 conda: 4.7.11 pytest: 5.0.1 IPython: 7.6.1 sphinx: 2.1.2 </details

from .core.alignment import align, broadcast from .core.combine import combine_by_coords, combine_nested from .core.common import ALL_DIMS, full_like, ones_like, zeros_likefrom .core.computation import apply_ufunc, corr, cov, dot, polyval, unify_chunks, wherefrom .core.computation import (    apply_ufunc,    corr,    cov,    cross,    dot,    polyval,    unify_chunks,    where,) from .core.concat import concat from .core.dataarray import DataArray from .core.dataset import Dataset


Question: Feature request: vector cross product xarray currently has the function for calculating arbitrary dot products which is indeed very handy. Sometimes, especially for physical applications I also need a vector cross product. I' wondering whether you would be interested in having as a wrapper of I currently use the following implementation: Do you want such a function (and possibly associated methods) in the namespace, or should it be in some other package? I didn't find a package which would be a good fit as this is close to core numpy functionality and isn't as domain specific as some geo packages. I'm not aware of some "xrphysics" package. I could make a PR if you'd want to have it in directly. <detailsINSTALLED VERSIONS commit: None python: 3.7.3 (default, Mar 27 2019, 22:11:17) [GCC 7.3.0] python-bits: 64 OS: Linux OS-release: 4.9.0-9-amd64 machine: x8664 processor: byteorder: little LCALL: None LANG: enUS.UTF-8 LOCALE: enUS.UTF-8 libhdf5: 1.10.4 libnetcdf: 4.6.1 xarray: 0.12.3 pandas: 0.24.2 numpy: 1.16.4 scipy: 1.3.0 netCDF4: 1.4.2 pydap: None h5netcdf: 0.7.4 h5py: 2.9.0 Nio: None zarr: None cftime: 1.0.3.4 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.2.1 dask: 2.1.0 distributed: 2.1.0 matplotlib: 3.1.0 cartopy: None seaborn: 0.9.0 numbagg: None setuptools: 41.0.1 pip: 19.1.1 conda: 4.7.11 pytest: 5.0.1 IPython: 7.6.1 sphinx: 2.1.2 </details

"dot",     "cov",     "corr",    "cross",     "full_like",     "get_options",     "infer_freq",diff --git a/xarray/core/computation.py b/xarray/core/computation.py-- a/xarray/core/computation.py++ b/xarray/core/computation.py


Question: Feature request: vector cross product xarray currently has the function for calculating arbitrary dot products which is indeed very handy. Sometimes, especially for physical applications I also need a vector cross product. I' wondering whether you would be interested in having as a wrapper of I currently use the following implementation: Do you want such a function (and possibly associated methods) in the namespace, or should it be in some other package? I didn't find a package which would be a good fit as this is close to core numpy functionality and isn't as domain specific as some geo packages. I'm not aware of some "xrphysics" package. I could make a PR if you'd want to have it in directly. <detailsINSTALLED VERSIONS commit: None python: 3.7.3 (default, Mar 27 2019, 22:11:17) [GCC 7.3.0] python-bits: 64 OS: Linux OS-release: 4.9.0-9-amd64 machine: x8664 processor: byteorder: little LCALL: None LANG: enUS.UTF-8 LOCALE: enUS.UTF-8 libhdf5: 1.10.4 libnetcdf: 4.6.1 xarray: 0.12.3 pandas: 0.24.2 numpy: 1.16.4 scipy: 1.3.0 netCDF4: 1.4.2 pydap: None h5netcdf: 0.7.4 h5py: 2.9.0 Nio: None zarr: None cftime: 1.0.3.4 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.2.1 dask: 2.1.0 distributed: 2.1.0 matplotlib: 3.1.0 cartopy: None seaborn: 0.9.0 numbagg: None setuptools: 41.0.1 pip: 19.1.1 conda: 4.7.11 pytest: 5.0.1 IPython: 7.6.1 sphinx: 2.1.2 </details

if TYPE_CHECKING:     from .coordinates import Coordinates<ins>    from .dataarray import DataArray</ins>     from .dataset import Dataset     from .types import T_Xarray


Question: Feature request: vector cross product xarray currently has the function for calculating arbitrary dot products which is indeed very handy. Sometimes, especially for physical applications I also need a vector cross product. I' wondering whether you would be interested in having as a wrapper of I currently use the following implementation: Do you want such a function (and possibly associated methods) in the namespace, or should it be in some other package? I didn't find a package which would be a good fit as this is close to core numpy functionality and isn't as domain specific as some geo packages. I'm not aware of some "xrphysics" package. I could make a PR if you'd want to have it in directly. <detailsINSTALLED VERSIONS commit: None python: 3.7.3 (default, Mar 27 2019, 22:11:17) [GCC 7.3.0] python-bits: 64 OS: Linux OS-release: 4.9.0-9-amd64 machine: x8664 processor: byteorder: little LCALL: None LANG: enUS.UTF-8 LOCALE: enUS.UTF-8 libhdf5: 1.10.4 libnetcdf: 4.6.1 xarray: 0.12.3 pandas: 0.24.2 numpy: 1.16.4 scipy: 1.3.0 netCDF4: 1.4.2 pydap: None h5netcdf: 0.7.4 h5py: 2.9.0 Nio: None zarr: None cftime: 1.0.3.4 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.2.1 dask: 2.1.0 distributed: 2.1.0 matplotlib: 3.1.0 cartopy: None seaborn: 0.9.0 numbagg: None setuptools: 41.0.1 pip: 19.1.1 conda: 4.7.11 pytest: 5.0.1 IPython: 7.6.1 sphinx: 2.1.2 </details

return corr  <ins>def cross(    a: Union[DataArray, Variable], b: Union[DataArray, Variable], *, dim: Hashable) -> Union[DataArray, Variable]:    """    Compute the cross product of two (arrays of) vectors.    The cross product of `a` and `b` in :math:`R^3` is a vector    perpendicular to both `a` and `b`. The vectors in `a` and `b` are    defined by the values along the dimension `dim` and can have sizes    1, 2 or 3. Where the size of either `a` or `b` is    1 or 2, the remaining components of the input vector is assumed to    be zero and the cross product calculated accordingly. In cases where    both input vectors have dimension 2, the z-component of the cross    product is returned.    Parameters    ----------    a, b : DataArray or Variable        Components of the first and second vector(s).    dim : hashable        The dimension along which the cross product will be computed.        Must be available in both vectors.    Examples    --------    Vector cross-product with 3 dimensions:    >>> a = xr.DataArray([1, 2, 3])    >>> b = xr.DataArray([4, 5, 6])    >>> xr.cross(a, b, dim="dim_0")    <xarray.DataArray (dim_0: 3)>    array([-3,  6, -3])    Dimensions without coordinates: dim_0    Vector cross-product with 2 dimensions, returns in the perpendicular    direction:    >>> a = xr.DataArray([1, 2])    >>> b = xr.DataArray([4, 5])    >>> xr.cross(a, b, dim="dim_0")    <xarray.DataArray ()>    array(-3)    Vector cross-product with 3 dimensions but zeros at the last axis    yields the same results as with 2 dimensions:    >>> a = xr.DataArray([1, 2, 0])    >>> b = xr.DataArray([4, 5, 0])    >>> xr.cross(a, b, dim="dim_0")    <xarray.DataArray (dim_0: 3)>    array([ 0,  0, -3])    Dimensions without coordinates: dim_0    One vector with dimension 2:    >>> a = xr.DataArray(    ...     [1, 2],    ...     dims=["cartesian"],    ...     coords=dict(cartesian=(["cartesian"], ["x", "y"])),    ... )    >>> b = xr.DataArray(    ...     [4, 5, 6],    ...     dims=["cartesian"],    ...     coords=dict(cartesian=(["cartesian"], ["x", "y", "z"])),    ... )    >>> xr.cross(a, b, dim="cartesian")    <xarray.DataArray (cartesian: 3)>    array([12, -6, -3])    Coordinates:      * cartesian  (cartesian) <U1 'x' 'y' 'z'    One vector with dimension 2 but coords in other positions:    >>> a = xr.DataArray(    ...     [1, 2],    ...     dims=["cartesian"],    ...     coords=dict(cartesian=(["cartesian"], ["x", "z"])),    ... )    >>> b = xr.DataArray(    ...     [4, 5, 6],    ...     dims=["cartesian"],    ...     coords=dict(cartesian=(["cartesian"], ["x", "y", "z"])),    ... )    >>> xr.cross(a, b, dim="cartesian")    <xarray.DataArray (cartesian: 3)>    array([-10,   2,   5])    Coordinates:      * cartesian  (cartesian) <U1 'x' 'y' 'z'    Multiple vector cross-products. Note that the direction of the    cross product vector is defined by the right-hand rule:    >>> a = xr.DataArray(    ...     [[1, 2, 3], [4, 5, 6]],    ...     dims=("time", "cartesian"),    ...     coords=dict(    ...         time=(["time"], [0, 1]),    ...         cartesian=(["cartesian"], ["x", "y", "z"]),    ...     ),    ... )    >>> b = xr.DataArray(    ...     [[4, 5, 6], [1, 2, 3]],    ...     dims=("time", "cartesian"),    ...     coords=dict(    ...         time=(["time"], [0, 1]),    ...         cartesian=(["cartesian"], ["x", "y", "z"]),    ...     ),    ... )    >>> xr.cross(a, b, dim="cartesian")    <xarray.DataArray (time: 2, cartesian: 3)>    array([[-3,  6, -3],           [ 3, -6,  3]])    Coordinates:      * time       (time) int64 0 1      * cartesian  (cartesian) <U1 'x' 'y' 'z'    Cross can be called on Datasets by converting to DataArrays and later    back to a Dataset:    >>> ds_a = xr.Dataset(dict(x=("dim_0", [1]), y=("dim_0", [2]), z=("dim_0", [3])))    >>> ds_b = xr.Dataset(dict(x=("dim_0", [4]), y=("dim_0", [5]), z=("dim_0", [6])))    >>> c = xr.cross(    ...     ds_a.to_array("cartesian"), ds_b.to_array("cartesian"), dim="cartesian"    ... )    >>> c.to_dataset(dim="cartesian")    <xarray.Dataset>    Dimensions:  (dim_0: 1)    Dimensions without coordinates: dim_0    Data variables:        x        (dim_0) int64 -3        y        (dim_0) int64 6        z        (dim_0) int64 -3    See Also    --------    numpy.cross : Corresponding numpy function    """    if dim not in a.dims:        raise ValueError(f"Dimension {dim!r} not on a")    elif dim not in b.dims:        raise ValueError(f"Dimension {dim!r} not on b")    if not 1 <= a.sizes[dim] <= 3:        raise ValueError(            f"The size of {dim!r} on a must be 1, 2, or 3 to be "            f"compatible with a cross product but is {a.sizes[dim]}"        )    elif not 1 <= b.sizes[dim] <= 3:        raise ValueError(            f"The size of {dim!r} on b must be 1, 2, or 3 to be "            f"compatible with a cross product but is {b.sizes[dim]}"        )    all_dims = list(dict.fromkeys(a.dims + b.dims))    if a.sizes[dim] != b.sizes[dim]:        # Arrays have different sizes. Append zeros where the smaller        # array is missing a value, zeros will not affect np.cross:        if (            not isinstance(a, Variable)  # Only used to make mypy happy.            and dim in getattr(a, "coords", {})            and not isinstance(b, Variable)  # Only used to make mypy happy.            and dim in getattr(b, "coords", {})        ):            # If the arrays have coords we know which indexes to fill            # with zeros:            a, b = align(                a,                b,                fill_value=0,                join="outer",                exclude=set(all_dims) - {dim},            )        elif min(a.sizes[dim], b.sizes[dim]) == 2:            # If the array doesn't have coords we can only infer            # that it has composite values if the size is at least 2.            # Once padded, rechunk the padded array because apply_ufunc            # requires core dimensions not to be chunked:            if a.sizes[dim] < b.sizes[dim]:                a = a.pad({dim: (0, 1)}, constant_values=0)                # TODO: Should pad or apply_ufunc handle correct chunking?                a = a.chunk({dim: -1}) if is_duck_dask_array(a.data) else a            else:                b = b.pad({dim: (0, 1)}, constant_values=0)                # TODO: Should pad or apply_ufunc handle correct chunking?                b = b.chunk({dim: -1}) if is_duck_dask_array(b.data) else b        else:            raise ValueError(                f"{dim!r} on {'a' if a.sizes[dim] == 1 else 'b'} is incompatible:"                " dimensions without coordinates must have have a length of 2 or 3"            )    c = apply_ufunc(        np.cross,        a,        b,        input_core_dims=[[dim], [dim]],        output_core_dims=[[dim] if a.sizes[dim] == 3 else []],        dask="parallelized",        output_dtypes=[np.result_type(a, b)],    )    c = c.transpose(*all_dims, missing_dims="ignore")    return c</ins> def dot(*arrays, dims=None, **kwargs):     """Generalized dot product for xarray objects. Like np.einsum, but     provides a simpler interface based on array dimensions.


Question: Increase default This must have been introduced into somewhere around version 0.17. First of all this limit breaks backwards compatibility in the output format with or something similar on the console. Second, the default of 12 is much too low imo and makes no sense, in particular since terminals usually have a scrollback buffer and notebook cells can be made scrollable. I use frequently to check that all variables made it into the data set correctly, which is meaningless when lines are skipped with this default limit. And it broke my doctests that I wrote to do exactly that (thanks for that btw.). So if not removed, could the default be at least increased to a sensible number like 100 or 1000 or ? (I'd personally prefer much higher or even no limit, but I guess that is not an option.) Cheers.

):     if col_width is None:         col_width = _calculate_col_width(mapping)    if max_rows is None:        max_rows = OPTIONS["display_max_rows"]     summary = [f"{title}:"]     if mapping:         len_mapping = len(mapping)         if not _get_boolean_with_default(expand_option_name, default=True):             summary = [f"{summary[0]} ({len_mapping})"]        elif len_mapping > max_rows:        elif max_rows is not None and len_mapping > max_rows:             summary = [f"{summary[0]} ({max_rows}/{len_mapping})"]             first_rows = max_rows // 2 + max_rows % 2             keys = list(mapping.keys())


Question: Increase default This must have been introduced into somewhere around version 0.17. First of all this limit breaks backwards compatibility in the output format with or something similar on the console. Second, the default of 12 is much too low imo and makes no sense, in particular since terminals usually have a scrollback buffer and notebook cells can be made scrollable. I use frequently to check that all variables made it into the data set correctly, which is meaningless when lines are skipped with this default limit. And it broke my doctests that I wrote to do exactly that (thanks for that btw.). So if not removed, could the default be at least increased to a sensible number like 100 or 1000 or ? (I'd personally prefer much higher or even no limit, but I guess that is not an option.) Cheers.

)  def coords_repr(coords, col_width=None):def coords_repr(coords, col_width=None, max_rows=None):     if col_width is None:         col_width = _calculate_col_width(_get_col_items(coords))     return _mapping_repr(


Question: Increase default This must have been introduced into somewhere around version 0.17. First of all this limit breaks backwards compatibility in the output format with or something similar on the console. Second, the default of 12 is much too low imo and makes no sense, in particular since terminals usually have a scrollback buffer and notebook cells can be made scrollable. I use frequently to check that all variables made it into the data set correctly, which is meaningless when lines are skipped with this default limit. And it broke my doctests that I wrote to do exactly that (thanks for that btw.). So if not removed, could the default be at least increased to a sensible number like 100 or 1000 or ? (I'd personally prefer much higher or even no limit, but I guess that is not an option.) Cheers.

summarizer=summarize_coord,         expand_option_name="display_expand_coords",         col_width=col_width,<ins>        max_rows=max_rows,</ins>     )


Question: Increase default This must have been introduced into somewhere around version 0.17. First of all this limit breaks backwards compatibility in the output format with or something similar on the console. Second, the default of 12 is much too low imo and makes no sense, in particular since terminals usually have a scrollback buffer and notebook cells can be made scrollable. I use frequently to check that all variables made it into the data set correctly, which is meaningless when lines are skipped with this default limit. And it broke my doctests that I wrote to do exactly that (thanks for that btw.). So if not removed, could the default be at least increased to a sensible number like 100 or 1000 or ? (I'd personally prefer much higher or even no limit, but I guess that is not an option.) Cheers.

summary = ["<xarray.{}>".format(type(ds).__name__)]      col_width = _calculate_col_width(_get_col_items(ds.variables))    max_rows = OPTIONS["display_max_rows"]      dims_start = pretty_print("Dimensions:", col_width)     summary.append("{}({})".format(dims_start, dim_summary(ds)))      if ds.coords:        summary.append(coords_repr(ds.coords, col_width=col_width))        summary.append(coords_repr(ds.coords, col_width=col_width, max_rows=max_rows))      unindexed_dims_str = unindexed_dims_repr(ds.dims, ds.coords)     if unindexed_dims_str:         summary.append(unindexed_dims_str)     summary.append(data_vars_repr(ds.data_vars, col_width=col_width))    summary.append(data_vars_repr(ds.data_vars, col_width=col_width, max_rows=max_rows))      if ds.attrs:        summary.append(attrs_repr(ds.attrs))        summary.append(attrs_repr(ds.attrs, max_rows=max_rows))      return "\n".join(summary)


Question: Limit number of displayed dimensions in repr <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Dimension doesn't seem to be limited when there are too many of them. See example below. This slows down the repr significantly and is quite unreadable to me. What you expected to happen: To be limited so that it aligns with whatever the maximum line length is for variables. It's also fine if it continues on a couple of rows below in similar fashion to variables. Minimal Complete Verifiable Example: This is probably a bit of an edge case. My real datasets usually have around 12 "dimensions" and coords, +2000 variables, 50 attrs. Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.8 (default, Feb 20 2021, 15:50:08) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 byteorder: little LCALL: None LANG: en libhdf5: 1.10.6 libnetcdf: None xarray: 0.18.2 pandas: 1.2.4 numpy: 1.20.3 scipy: 1.6.3 netCDF4: None pydap: None h5netcdf: None h5py: 3.2.1 Nio: None zarr: None cftime: None nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: None seaborn: 0.11.1 numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.1.2 conda: 4.10.1 pytest: 6.2.4 IPython: 7.24.1 sphinx: 4.0.2 </details

import functools from datetime import datetime, timedelta from itertools import chain, zip_longestfrom typing import Hashablefrom typing import Collection, Hashable, Optional  import numpy as np import pandas as pd


Question: Limit number of displayed dimensions in repr <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Dimension doesn't seem to be limited when there are too many of them. See example below. This slows down the repr significantly and is quite unreadable to me. What you expected to happen: To be limited so that it aligns with whatever the maximum line length is for variables. It's also fine if it continues on a couple of rows below in similar fashion to variables. Minimal Complete Verifiable Example: This is probably a bit of an edge case. My real datasets usually have around 12 "dimensions" and coords, +2000 variables, 50 attrs. Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.8 (default, Feb 20 2021, 15:50:08) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 byteorder: little LCALL: None LANG: en libhdf5: 1.10.6 libnetcdf: None xarray: 0.18.2 pandas: 1.2.4 numpy: 1.20.3 scipy: 1.6.3 netCDF4: None pydap: None h5netcdf: None h5py: 3.2.1 Nio: None zarr: None cftime: None nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: None seaborn: 0.11.1 numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.1.2 conda: 4.10.1 pytest: 6.2.4 IPython: 7.24.1 sphinx: 4.0.2 </details

return np.ravel(np.asarray(array[indexer])).tolist()  <ins>def calc_max_rows_first(max_rows: int) -> int:    """Calculate the first rows to maintain the max number of rows."""    return max_rows // 2 + max_rows % 2def calc_max_rows_last(max_rows: int) -> int:    """Calculate the last rows to maintain the max number of rows."""    return max_rows // 2</ins> def format_timestamp(t):     """Cast given object to a Timestamp and return a nicely formatted string"""     # Timestamp is only valid for 1678 to 2262


Question: Limit number of displayed dimensions in repr <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Dimension doesn't seem to be limited when there are too many of them. See example below. This slows down the repr significantly and is quite unreadable to me. What you expected to happen: To be limited so that it aligns with whatever the maximum line length is for variables. It's also fine if it continues on a couple of rows below in similar fashion to variables. Minimal Complete Verifiable Example: This is probably a bit of an edge case. My real datasets usually have around 12 "dimensions" and coords, +2000 variables, 50 attrs. Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.8 (default, Feb 20 2021, 15:50:08) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 byteorder: little LCALL: None LANG: en libhdf5: 1.10.6 libnetcdf: None xarray: 0.18.2 pandas: 1.2.4 numpy: 1.20.3 scipy: 1.6.3 netCDF4: None pydap: None h5netcdf: None h5py: 3.2.1 Nio: None zarr: None cftime: None nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: None seaborn: 0.11.1 numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.1.2 conda: 4.10.1 pytest: 6.2.4 IPython: 7.24.1 sphinx: 4.0.2 </details

summary = [f"{summary[0]} ({len_mapping})"]         elif max_rows is not None and len_mapping > max_rows:             summary = [f"{summary[0]} ({max_rows}/{len_mapping})"]            first_rows = max_rows // 2 + max_rows % 2            first_rows = calc_max_rows_first(max_rows)             keys = list(mapping.keys())             summary += [summarizer(k, mapping[k], col_width) for k in keys[:first_rows]]             if max_rows > 1:                last_rows = max_rows // 2                last_rows = calc_max_rows_last(max_rows)                 summary += [pretty_print("    ...", col_width) + " ..."]                 summary += [                     summarizer(k, mapping[k], col_width) for k in keys[-last_rows:]


Question: Limit number of displayed dimensions in repr <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Dimension doesn't seem to be limited when there are too many of them. See example below. This slows down the repr significantly and is quite unreadable to me. What you expected to happen: To be limited so that it aligns with whatever the maximum line length is for variables. It's also fine if it continues on a couple of rows below in similar fashion to variables. Minimal Complete Verifiable Example: This is probably a bit of an edge case. My real datasets usually have around 12 "dimensions" and coords, +2000 variables, 50 attrs. Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.8 (default, Feb 20 2021, 15:50:08) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 byteorder: little LCALL: None LANG: en libhdf5: 1.10.6 libnetcdf: None xarray: 0.18.2 pandas: 1.2.4 numpy: 1.20.3 scipy: 1.6.3 netCDF4: None pydap: None h5netcdf: None h5py: 3.2.1 Nio: None zarr: None cftime: None nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: None seaborn: 0.11.1 numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.1.2 conda: 4.10.1 pytest: 6.2.4 IPython: 7.24.1 sphinx: 4.0.2 </details

return ", ".join(elements)  def unindexed_dims_repr(dims, coords):def _element_formatter(    elements: Collection[Hashable],    col_width: int,    max_rows: Optional[int] = None,    delimiter: str = ", ",) -> str:    """    Formats elements for better readability.    Once it becomes wider than the display width it will create a newline and    continue indented to col_width.    Once there are more rows than the maximum displayed rows it will start    removing rows.    Parameters    ----------    elements : Collection of hashable        Elements to join together.    col_width : int        The width to indent to if a newline has been made.    max_rows : int, optional        The maximum number of allowed rows. The default is None.    delimiter : str, optional        Delimiter to use between each element. The default is ", ".    """    elements_len = len(elements)    out = [""]    length_row = 0    for i, v in enumerate(elements):        delim = delimiter if i < elements_len - 1 else ""        v_delim = f"{v}{delim}"        length_element = len(v_delim)        length_row += length_element        # Create a new row if the next elements makes the print wider than        # the maximum display width:        if col_width + length_row > OPTIONS["display_width"]:            out[-1] = out[-1].rstrip()  # Remove trailing whitespace.            out.append("\n" + pretty_print("", col_width) + v_delim)            length_row = length_element        else:            out[-1] += v_delim    # If there are too many rows of dimensions trim some away:    if max_rows and (len(out) > max_rows):        first_rows = calc_max_rows_first(max_rows)        last_rows = calc_max_rows_last(max_rows)        out = (            out[:first_rows]            + ["\n" + pretty_print("", col_width) + "..."]            + (out[-last_rows:] if max_rows > 1 else [])        )    return "".join(out)def dim_summary_limited(obj, col_width: int, max_rows: Optional[int] = None) -> str:    elements = [f"{k}: {v}" for k, v in obj.sizes.items()]    return _element_formatter(elements, col_width, max_rows)def unindexed_dims_repr(dims, coords, max_rows: Optional[int] = None):     unindexed_dims = [d for d in dims if d not in coords]     if unindexed_dims:        dims_str = ", ".join(f"{d}" for d in unindexed_dims)        return "Dimensions without coordinates: " + dims_str        dims_start = "Dimensions without coordinates: "        dims_str = _element_formatter(            unindexed_dims, col_width=len(dims_start), max_rows=max_rows        )        return dims_start + dims_str     else:         return None


Question: Limit number of displayed dimensions in repr <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Dimension doesn't seem to be limited when there are too many of them. See example below. This slows down the repr significantly and is quite unreadable to me. What you expected to happen: To be limited so that it aligns with whatever the maximum line length is for variables. It's also fine if it continues on a couple of rows below in similar fashion to variables. Minimal Complete Verifiable Example: This is probably a bit of an edge case. My real datasets usually have around 12 "dimensions" and coords, +2000 variables, 50 attrs. Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.8 (default, Feb 20 2021, 15:50:08) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 byteorder: little LCALL: None LANG: en libhdf5: 1.10.6 libnetcdf: None xarray: 0.18.2 pandas: 1.2.4 numpy: 1.20.3 scipy: 1.6.3 netCDF4: None pydap: None h5netcdf: None h5py: 3.2.1 Nio: None zarr: None cftime: None nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: None seaborn: 0.11.1 numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.1.2 conda: 4.10.1 pytest: 6.2.4 IPython: 7.24.1 sphinx: 4.0.2 </details

def array_repr(arr):     from .variable import Variable <ins>    max_rows = OPTIONS["display_max_rows"]</ins>     # used for DataArray, Variable and IndexVariable     if hasattr(arr, "name") and arr.name is not None:         name_str = f"{arr.name!r} "


Question: Limit number of displayed dimensions in repr <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Dimension doesn't seem to be limited when there are too many of them. See example below. This slows down the repr significantly and is quite unreadable to me. What you expected to happen: To be limited so that it aligns with whatever the maximum line length is for variables. It's also fine if it continues on a couple of rows below in similar fashion to variables. Minimal Complete Verifiable Example: This is probably a bit of an edge case. My real datasets usually have around 12 "dimensions" and coords, +2000 variables, 50 attrs. Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.8 (default, Feb 20 2021, 15:50:08) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 byteorder: little LCALL: None LANG: en libhdf5: 1.10.6 libnetcdf: None xarray: 0.18.2 pandas: 1.2.4 numpy: 1.20.3 scipy: 1.6.3 netCDF4: None pydap: None h5netcdf: None h5py: 3.2.1 Nio: None zarr: None cftime: None nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: None seaborn: 0.11.1 numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.1.2 conda: 4.10.1 pytest: 6.2.4 IPython: 7.24.1 sphinx: 4.0.2 </details

else:         data_repr = inline_variable_array_repr(arr.variable, OPTIONS["display_width"])     start = f"<xarray.{type(arr).__name__} {name_str}"    dims = dim_summary_limited(arr, col_width=len(start) + 1, max_rows=max_rows)     summary = [        "<xarray.{} {}({})>".format(type(arr).__name__, name_str, dim_summary(arr)),        f"{start}({dims})>",         data_repr,     ]      if hasattr(arr, "coords"):         if arr.coords:            summary.append(repr(arr.coords))            col_width = _calculate_col_width(_get_col_items(arr.coords))            summary.append(                coords_repr(arr.coords, col_width=col_width, max_rows=max_rows)            )         unindexed_dims_str = unindexed_dims_repr(arr.dims, arr.coords)        unindexed_dims_str = unindexed_dims_repr(            arr.dims, arr.coords, max_rows=max_rows        )         if unindexed_dims_str:             summary.append(unindexed_dims_str)


Question: Limit number of displayed dimensions in repr <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: Dimension doesn't seem to be limited when there are too many of them. See example below. This slows down the repr significantly and is quite unreadable to me. What you expected to happen: To be limited so that it aligns with whatever the maximum line length is for variables. It's also fine if it continues on a couple of rows below in similar fashion to variables. Minimal Complete Verifiable Example: This is probably a bit of an edge case. My real datasets usually have around 12 "dimensions" and coords, +2000 variables, 50 attrs. Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.8 (default, Feb 20 2021, 15:50:08) [MSC v.1916 64 bit (AMD64)] python-bits: 64 OS: Windows OS-release: 10 byteorder: little LCALL: None LANG: en libhdf5: 1.10.6 libnetcdf: None xarray: 0.18.2 pandas: 1.2.4 numpy: 1.20.3 scipy: 1.6.3 netCDF4: None pydap: None h5netcdf: None h5py: 3.2.1 Nio: None zarr: None cftime: None nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.05.0 distributed: 2021.05.0 matplotlib: 3.4.2 cartopy: None seaborn: 0.11.1 numbagg: None pint: None setuptools: 49.6.0.post20210108 pip: 21.1.2 conda: 4.10.1 pytest: 6.2.4 IPython: 7.24.1 sphinx: 4.0.2 </details

max_rows = OPTIONS["display_max_rows"]      dims_start = pretty_print("Dimensions:", col_width)    summary.append("{}({})".format(dims_start, dim_summary(ds)))    dims_values = dim_summary_limited(ds, col_width=col_width + 1, max_rows=max_rows)    summary.append(f"{dims_start}({dims_values})")      if ds.coords:         summary.append(coords_repr(ds.coords, col_width=col_width, max_rows=max_rows))     unindexed_dims_str = unindexed_dims_repr(ds.dims, ds.coords)    unindexed_dims_str = unindexed_dims_repr(ds.dims, ds.coords, max_rows=max_rows)     if unindexed_dims_str:         summary.append(unindexed_dims_str)


Question: Complex LaTeX expressions in s aren't rendered correctly when plotting <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: When I try to give a variable a that's a complex latex expression and then plot that variable the expression doesn't get rendered by latex What you expected to happen: I expected the name to get rendered by latex Minimal Complete Verifiable Example: In the example below I'm plotting a variable with a complex via xarray and then plotting it again (in a separate figure) using only matplotlib and manually setting . The matplotlib-only version works fine (right), but the xarray version doesn't render (left). ! Anything else we need to know?: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.9.2 (default, Mar 3 2021, 20:02:32) [GCC 7.3.0] python-bits: 64 OS: Linux OS-release: 5.10.53-1-MANJARO machine: x8664 processor: byteorder: little LCALL: None LANG: enUS.UTF-8 LOCALE: enUS.UTF-8 libhdf5: 1.10.6 libnetcdf: 4.6.1 xarray: 0.17.0 pandas: 1.2.3 numpy: 1.19.2 scipy: 1.5.3 netCDF4: 1.5.6 pydap: None h5netcdf: None h5py: None Nio: None zarr: None cftime: 1.2.1 nctimeaxis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.04.0 distributed: 2021.04.0 matplotlib: 3.3.4 cartopy: 0.18.0 seaborn: None numbagg: None pint: 0.17 setuptools: 52.0.0.post20210125 pip: 21.0.1 conda: None pytest: None IPython: 7.22.0 sphinx: None </details

else:         units = _get_units_from_attrs(da)     return "\n".join(textwrap.wrap(name + extra + units, 30))    # Treat `name` differently if it's a latex sequence    if name.startswith("$") and (name.count("$") % 2 == 0):        return "$\n$".join(            textwrap.wrap(name + extra + units, 60, break_long_words=False)        )    else:        return "\n".join(textwrap.wrap(name + extra + units, 30))   def _interval_to_mid_points(array):


Question: Dask error on What happened: When I use on two Dataarrays I get a error. Notice that dask is not installed in my environement. What you expected to happen: Obtain the correlation values without dask interfering (as it should be optional in my understanding) Minimal Complete Verifiable Example: Results in: Environment:

da = da.where(~missing_vals)             return da         else:            return da            # ensure consistent return dtype            return da.astype(float)      da_a = da_a.map_blocks(_get_valid_values, args=[da_b])     da_b = da_b.map_blocks(_get_valid_values, args=[da_a])diff --git a/xarray/core/parallel.py b/xarray/core/parallel.py-- a/xarray/core/parallel.py++ b/xarray/core/parallel.py


Question: Dask error on What happened: When I use on two Dataarrays I get a error. Notice that dask is not installed in my environement. What you expected to happen: Obtain the correlation values without dask interfering (as it should be optional in my understanding) Minimal Complete Verifiable Example: Results in: Environment:

from .alignment import align from .dataarray import DataArray from .dataset import Dataset<ins>from .pycompat import is_dask_collection</ins>  try:     import dask


Question: Dask error on What happened: When I use on two Dataarrays I get a error. Notice that dask is not installed in my environement. What you expected to happen: Obtain the correlation values without dask interfering (as it should be optional in my understanding) Minimal Complete Verifiable Example: Results in: Environment:

raise TypeError("kwargs must be a mapping (for example, a dict)")      for value in kwargs.values():        if dask.is_dask_collection(value):        if is_dask_collection(value):             raise TypeError(                 "Cannot pass dask collections in kwargs yet. Please compute or "                 "load values before passing to map_blocks."             )     if not dask.is_dask_collection(obj):    if not is_dask_collection(obj):         return func(obj, *args, **kwargs)      all_args = [obj] + list(args)diff --git a/xarray/core/pycompat.py b/xarray/core/pycompat.py-- a/xarray/core/pycompat.py++ b/xarray/core/pycompat.py


Question: Dask error on What happened: When I use on two Dataarrays I get a error. Notice that dask is not installed in my environement. What you expected to happen: Obtain the correlation values without dask interfering (as it should be optional in my understanding) Minimal Complete Verifiable Example: Results in: Environment:

self.available = duck_array_module is not None  def is_duck_dask_array(x):def is_dask_collection(x):     if DuckArrayModule("dask").available:         from dask.base import is_dask_collection         return is_duck_array(x) and is_dask_collection(x)        return is_dask_collection(x)     else:         return False  def is_duck_dask_array(x):    return is_duck_array(x) and is_dask_collection(x) dsk = DuckArrayModule("dask") dask_version = dsk.version dask_array_type = dsk.type


Question: Dataset groupby returning DataArray broken in some cases Got a TypeError when resampling a dataset along a dimension, mapping a function to each group. The function returns a DataArray. Failed with : This worked before the merging of . A DataArray was returned as expected. In the docstring of it is not made clear that the passed function should return a dataset, but the opposite is also not said. This worked before and I think the issues comes from , which introduced different signatures for (which is called in my case) and (which is expected by the new ). If the function passed to should only return s then I believe a more explicit error is needed, as well as some notice in the docs and a breaking change entry in the changelog. If s should be accepted, then we have a regression here. I may have time to help on this. <detailsINSTALLED VERSIONS commit: None python: 3.9.6 (default, Jul 11 2021, 03:39:48) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 5.16.13-arch1-1 machine: x8664 processor: byteorder: little LCALL: None LANG: frCA.utf8 LOCALE: ('frCA', 'UTF-8') libhdf5: 1.12.0 libnetcdf: 4.7.4 xarray: 2022.3.1.dev16+g3ead17ea pandas: 1.4.0 numpy: 1.20.3 scipy: 1.7.1 netCDF4: 1.5.7 pydap: None h5netcdf: 0.11.0 h5py: 3.4.0 Nio: None zarr: 2.10.0 cftime: 1.5.0 nctime_axis: 1.3.1 PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.08.0 distributed: 2021.08.0 matplotlib: 3.4.3 cartopy: None seaborn: None numbagg: None fsspec: 2021.07.0 cupy: None pint: 0.18 sparse: None setuptools: 57.4.0 pip: 21.2.4 conda: None pytest: 6.2.5 IPython: 8.0.1 sphinx: 4.1.2 </details

if coord is not None and dim not in applied_example.dims:             index, index_vars = create_default_index_implicit(coord)             indexes = {k: index for k in index_vars}            combined = combined._overwrite_indexes(indexes, variables=index_vars)            combined = combined._overwrite_indexes(indexes, index_vars)         combined = self._maybe_restore_empty_groups(combined)         combined = self._maybe_unstack(combined)         return combined


Question: DataArray groupby returning Dataset broken in some cases This is a the reverse problem of , the method seems broken when the mapped function returns a Dataset (which worked before ). No response I guess the same solution as could be used! <detailsINSTALLED VERSIONS commit: None python: 3.9.6 (default, Jul 11 2021, 03:39:48) [GCC 9.3.0] python-bits: 64 OS: Linux OS-release: 5.16.13-arch1-1 machine: x8664 processor: byteorder: little LCALL: None LANG: frCA.utf8 LOCALE: ('frCA', 'UTF-8') libhdf5: 1.12.0 libnetcdf: 4.7.4 xarray: 2022.3.1.dev16+g3ead17ea pandas: 1.4.0 numpy: 1.20.3 scipy: 1.7.1 netCDF4: 1.5.7 pydap: None h5netcdf: 0.11.0 h5py: 3.4.0 Nio: None zarr: 2.10.0 cftime: 1.5.0 nctime_axis: 1.3.1 PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.08.0 distributed: 2021.08.0 matplotlib: 3.4.3 cartopy: None seaborn: None numbagg: None fsspec: 2021.07.0 cupy: None pint: 0.18 sparse: None setuptools: 57.4.0 pip: 21.2.4 conda: None pytest: 6.2.5 IPython: 8.0.1 sphinx: 4.1.2 </details

if coord is not None and dim not in applied_example.dims:             index, index_vars = create_default_index_implicit(coord)             indexes = {k: index for k in index_vars}            combined = combined._overwrite_indexes(indexes, coords=index_vars)            combined = combined._overwrite_indexes(indexes, index_vars)         combined = self._maybe_restore_empty_groups(combined)         combined = self._maybe_unstack(combined)         return combined


Question: Very poor html repr performance on large multi-indexes <!-- Please include a self-contained copy-pastable example that generates the issue if possible. Please be concise with code posted. See guidelines below on how to provide a good bug report: Craft Minimal Bug Reports: Minimal Complete Verifiable Examples: Bug reports that follow these guidelines are easier to diagnose, and so are often handled much more quickly. --What happened: We have catestrophic performance on the html repr of some long multi-indexed data arrays. Here's a case of it taking 12s. Minimal Complete Verifiable Example: Anything else we need to know?: I thought we'd fixed some issues here: Environment: <details<summaryOutput of <ttxr.showversions()</tt</summaryINSTALLED VERSIONS commit: None python: 3.8.10 (default, May 9 2021, 13:21:55) [Clang 12.0.5 (clang-1205.0.22.9)] python-bits: 64 OS: Darwin OS-release: 20.4.0 machine: x8664 processor: i386 byteorder: little LCALL: None LANG: None LOCALE: ('enUS', 'UTF-8') libhdf5: None libnetcdf: None xarray: 0.18.2 pandas: 1.2.4 numpy: 1.20.3 scipy: 1.6.3 netCDF4: None pydap: None h5netcdf: None h5py: None Nio: None zarr: 2.8.3 cftime: 1.4.1 nctimeaxis: None PseudoNetCDF: None rasterio: 1.2.3 cfgrib: None iris: None bottleneck: 1.3.2 dask: 2021.06.1 distributed: 2021.06.1 matplotlib: 3.4.2 cartopy: None seaborn: 0.11.1 numbagg: 0.2.1 pint: None setuptools: 56.0.0 pip: 21.1.2 conda: None pytest: 6.2.4 IPython: 7.24.0 sphinx: 4.0.1 </details

# default to lower precision so a full (abbreviated) line can fit on     # one line with the default display_width    options = {"precision": 6, "linewidth": OPTIONS["display_width"], "threshold": 200}    options = {        "precision": 6,        "linewidth": OPTIONS["display_width"],        "threshold": OPTIONS["display_values_threshold"],    }     if array.ndim < 3:         edgeitems = 3     elif array.ndim == 3:diff --git a/xarray/core/indexing.py b/xarray/core/indexing.py-- a/xarray/core/indexing.py++ b/xarray/core/indexing.py