Fix drop_sel for a MultiIndex

[owena11]

This is a proposed fix to #10862 to allow consistent usage between sel and drop_sel for MultiIndexes. The current implementation seems to convert the labels to an array to handle the edge case of labels of type xr.DataArray. This change makes that edge case more explict and delegates the reponsibility for converting to an array if needed down to the indexer.

Exisitng indexes already do this and so the change shouldn't have any preformance implications:

• pandas.Index.drop - here

• pandas.MultiIndex.drop - here

• Closes Differing behaviour between sel and drop_sel for MultiIndexes #10862

• Tests added

[welcome]

Thank you for opening this pull request! It may take us a few days to respond here, so thank you for being patient.
If you have questions, some answers may be found in our contributing guidelines.

[owena11]

I've imported DataArray here as that seems to fit with the style in other parts of the codebase (here), however I'm not entirely sure why this is done.

[max-sixty]

I don't know this area that well, though it does seem to solve the immediate problem.

would anyone have alternative approaches that get at the root of the issue?

otherwise I would suggest merging this, maybe with a comment explaining, and then nothing prevents refactoring later...

(adding @benbovy , the indexing Czar, though others will also know more)

[owena11]

I don't know this area that well,

I have to admit the same! To try and provide more context I've dived down the git blame rabbit hole to explain the original reason for the cast to an array type within the code.

It was introduced in this PR #3177. The PR intorduces a whole bunch of type hints for the old drop method before the split to drop_vars / drop_sel refereced indexes: 'OrderedDict[Any, pd.Index]'. At that time the Index.drop didn't have a type signature apart from a docstring in pandas unless they're stored elsewhere. So the best theory I have is that is was related to matching the types from somewhere in the chain.