-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
API: Use different exception type when MultiIndex indexing fails due to index not being lexsorted #11897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
pls show a complete example uptop |
Here is an example: mi = pd.MultiIndex.from_tuples([('z','a'),('x','a'),('y','b'),('x','b'),('y','a'),('z','b')], names=['one','two'])
df = pd.DataFrame([[i,10*i] for i in range(6)], index=mi, columns=['one','two'])
print(df.loc(axis=0)['z',:]) The last line fails with: Now consider where we do the sorting: df.sort_index(inplace=True)
print(df.loc(axis=0)['z',:])
print(df.loc(axis=0)['q',:]) The second line works because things are now sorted, but the last line fails with: So I'd like to be able to surround all of the above code with ways of detecting the 2 different errors, which will make debugging easier. |
I like this idea. To preserve backwards compatibility, we might make it a KeyError subclass. Note that there are also some cases where indexing non-multiindexes can raise a KeyError because the index is unsourced (notably, when slicing). |
would for sure have to be a |
@jreback So should I create the |
@Dr-Irv interested in working on this? |
Yes, but it might be a while, as I've got some other pressing issues. |
ERR: Change error message pandas-dev#14491 ENH: pandas-dev#11897 make lint work. ERR: pandas-dev#14491 change error message ERR: pandas-dev#14491 fix test for error message fixes based on jreback feedback fix indent issue Doc fixes Fixes per jreback comments
ERR: Change error message pandas-dev#14491
ERR: Change error message pandas-dev#14491
I'd like to be able to separately trap errors in indexing that are due to the lack of the
MultiIndex
being lexsorted. Right now, aKeyError
is raised, and the only way to tell if the error was due to the lack of a lexsort versus a missing key is to look at the text of the message.So I'd like to avoid code like this:
I'd rather write something like:
So could the designers accept a change where a different error is raised in case the index is not lexsorted? If so, I'll implement it.
The text was updated successfully, but these errors were encountered: