BUG: Incorrect levels of MultiIndex when creating a new DataFrame by dropping a row

[LastsForever]

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Note: Please read this guide detailing how to provide the necessary information for us to reproduce your bug.

Code Sample, a copy-pastable example

#%%
import pandas as pd
import numpy as np

#%%
df = pd.DataFrame(np.arange(16).reshape(4,4), index=pd.MultiIndex.from_arrays([list("AABB"), list("XYXY")]), columns=list("abcd"))
df

#%%
df.index, df.index.levels

#%%
df_new = df.drop(index="A")
df_new

#%%
df_new.index, df_new.index.levels

Problem description

[this should explain why the current behaviour is a problem and why the expected output is a better solution]
The levels of MultiIndex of DataFrame never change when creating a new DataFrame by dropping a row. When creating a new DataFrame, the levels should match the new MultiIndex.

Expected Output

df_new.index.levels
should be
FrozenList([['B'], ['X', 'Y']]))

Output of pd.show_versions()

[paste the output of pd.show_versions() here leaving a blank line after the details tag]

INSTALLED VERSIONS

commit : None
python : 3.7.7.final.0
python-bits : 64
OS : Darwin
OS-release : 19.4.0
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.UTF-8

pandas : 1.0.3
numpy : 1.18.1
pytz : 2019.3
dateutil : 2.8.1
pip : 20.0.2
setuptools : 46.1.3.post20200330
Cython : None
pytest : None
hypothesis : None
sphinx : 2.4.4
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 2.11.1
IPython : 7.13.0
pandas_datareader: None
bs4 : None
bottleneck : None
fastparquet : None
gcsfs : None
lxml.etree : None
matplotlib : 3.1.3
numexpr : None
odfpy : None
openpyxl : 3.0.3
pandas_gbq : None
pyarrow : None
pytables : None
pytest : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : 1.2.0
xlwt : 1.3.0
xlsxwriter : None
numba : None

[CloseChoice]

take

[CloseChoice]

This needs some more discussion. There is a test which explicitly forces that the dropped multilevel index is still present in levels: test_multiindex_contains_dropped.

Why do we enforce this behaviour?

[jorisvandenbossche]

This is so that the index level codes don't need to be recalculated. If you actually want to drop unused labels from the level, there is the MultiIndex.remove_unused_levels method.

So while this is certainly a potentially confusing behaviour, I think this is done on purpose.

[CloseChoice]

So what could be the reason behind this purpose? Performance?

If so, then I would suggest to cythonize remove_unused_levels or at least parts of it (as suggested in one of the comments inside the function)