API/BUG: raise only KeyError failed on geitem/loc lookups

[jbrockmendel]

• closes Inconsistent error where looking for label of wrong type #21567
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

ATM we raise a mix of KeyError and TypeError.

I'm in the process of going through the Indexing issues will see what else this closes.

[jbrockmendel]

As a follow-up to this, it turns out we can entirely rip out _convert_scalar_indexer, which will be really nice

[WillAyd]

I think this makes sense though may break some user code catching a TypeError, so if others agree at least worth a note maybe a deprecation

[jorisvandenbossche]

I don't think it is possible to do with a deprecation? Or how would people be able to avoid the deprecation?
We could maybe also have a custom exception class that inherits both ..

Apart of changing the API; I assume that those different errors where there initially to provide a more useful error message to the user (instead of just "KeyError: some_value") ?

[jreback]

ok I think this is reasonable, e.g. this highlites the difference between indexing a list for example with a non-integer (raises TypeError) and a dict with anything (raises KeyError). consistency is good.

As far as user impact; this is a change, but likely does not affect very many downstream users (who are likely catching both TypeError and KeyError).

would be ok with simply changing this (to raise KeyError), unless other objections.

[jreback]

can you add a whatsnew section in api-breaking. highlite what things changed as far as exception raised (be as specific as you can for the examples)

[jreback]

this is a good change, any objections @jorisvandenbossche

[WillAyd]

I guess this was originally inspired by Python getitem semantics?

https://docs.python.org/3/reference/datamodel.html#object.__getitem__

In any case probably tenuous on our end, so lgtm

[WillAyd]

Thanks @jbrockmendel