issue_comments

Not sure that #5692 will be ready for the next release so I'll do this in a separate PR.

👍 I can take care of it in #5692 or in a separate PR.

I don't have a strong opinion but would be good to do this before the next release.

👍 I can take care of it in #5692 or in a separate PR.

The "if method is not None" approach seems reasonable.

Exactly, yeah, those are the problematic lines. That's an elegant solution. I think it will work with the minor modification to raise a KeyError if any of the indices returned by get_indexer_nd are less than zero: python if method is not None: indexer = get_indexer_nd(self.index, label, method, tolerance) if np.any(indexer < 0): raise KeyError(f"not all values found in index {coord_name!r}") else: indexer = self.index.get_loc(label_value)

These lines seem to be the problematic place? https://github.com/pydata/xarray/blob/e26aec9500e04f3b926b248988b976dbfcb9c632/xarray/core/indexes.py#L233-L235

We might be able to do something like: python if method is not None: indexer = get_indexer_nd(self.index, label, method, tolerance) else: indexer = self.index.get_loc(label_value)

Thanks for the heads up @mathause. We'll need to think carefully about this with respect to partial datetime string indexing. DatetimeIndex.get_indexer and DatetimeIndex.get_loc behave differently with respect to datetime strings. get_indexer interprets strings as specific dates, while get_loc interprets them as ranges: ```

import pandas as pd times = pd.date_range("2000", periods=5) times.get_indexer(["2000"]) array([0]) times.get_loc("2000") slice(0, 5, None) `` In other words -- at least for partial datetime string indexing -- it may not be as simple as swapping inget_indexerforget_loc`.

Perhaps @jbrockmendel has thoughts on how we should approach this?