API/BUG: make .at raise same exceptions as .loc

[jbrockmendel]

• closes API/BUG: Inconsistent errors/msgs between loc vs at #31722
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

This also (very) indirectly addresses #31683 which in turn will let us get rid of CategoricalIndex.get_value altogether.

[WillAyd]

Should mention the KeyError here as well?

[jorisvandenbossche]

Can you check some timings for at? (as this is supposed to be the fast one)

How does this indirectly also address #31683 ? And if it does, shouldn't there be tests involving categorical / a whatsnew?

[jorisvandenbossche]

I have to say that I found the previous error message more readable ..

[jbrockmendel]

I generally agree, that suggests we should improve the existing messages for "loc"

[jbrockmendel]

Can you check some timings for at? (as this is supposed to be the fast one)

Yah we take a hit

In [2]: ser = pd.Series(range(10000))                                           
In [3]: %timeit ser.at[501]                                                     
4.54 µs ± 139 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)  # <-- master
7.8 µs ± 75.2 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)  # <-- PR

In [4]: df = ser.to_frame("A")                                                  
In [5]: %timeit df.at[501, "A"]                                                 
3.9 µs ± 25.4 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)  # <-- master
7.71 µs ± 99.4 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)  # <-- PR

We might get some of that back from #31709.

[jbrockmendel]

How does this indirectly also address #31683 ? And if it does, shouldn't there be tests involving categorical / a whatsnew?

With this in place, all the places from which index.get_value are called are preceeded by maybe_cast_scalar_indexer (except one in which the key is a tuple). That makes the call inside CategoricalIndex.get_value unnecessary, which addresses the motivating issue for #31683. The "indexing on CategoricalIndex is hard" problem is still a problem.

[jreback]

consistency is a huge + here, makes the code much better.

I am not sure if @WillAyd or @jorisvandenbossche have comments, but lgtm.

[WillAyd]

lgtm. parametrization will be a nice follow on

[jreback]

thanks @jbrockmendel

[jorisvandenbossche]

@jreback maybe you didn't notice, but this time I had a "request changes" open, as you asked previous time to indicate that you shouldn't merge without me having the chance to answer back.
If there is still discussion going on, please give it some time.

[jorisvandenbossche]

@jbrockmendel can you do a follow up with:

• fixing the performance regression
• fixing the usability regression in the error message

[jorisvandenbossche]

fixing the usability regression in the error message

Looking back at it, it's actually mainly the long fully qualified class name that is annoying, so that is an easy fix -> #31769