BUG: reset_index() and set_index() expands uint32 to uint64

[bergkvist]

• 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.

---

Code Sample, a copy-pastable example

xy = pd.Series(
    index=pd.Index([1,2,3], dtype='uint32', name='x'), 
    data=[4,5,6], dtype='uint32', name='y'
)


>>> xy.reset_index().dtypes
x    uint64
y    uint32
dtype: object


>>> xy.reset_index().set_index('y').index.dtype
dtype('uint64')

Problem description

When using reset_index() or set_index(), the datatype of the affected array is expanded from uint32 to uint64. The dtype should remain unaffected.

Expected Output

>>> xy.reset_index().dtypes
x    uint32
y    uint32
dtype: object


>>> xy.reset_index().set_index('y').index.dtype
dtype('uint32')

Output of pd.show_versions()

INSTALLED VERSIONS

commit : None
python : 3.7.3.final.0
python-bits : 64
OS : Linux
OS-release : 4.9.125-linuxkit
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : en_US.UTF-8
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 0.25.0
numpy : 1.17.0
pytz : 2019.2
dateutil : 2.8.0
pip : 19.2.1
setuptools : 41.0.1
Cython : 0.29.13
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : 4.5.0
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 2.10.1
IPython : 7.7.0
pandas_datareader: None
bs4 : 4.8.0
bottleneck : None
fastparquet : 0.3.2
gcsfs : None
lxml.etree : 4.5.0
matplotlib : 3.1.1
numexpr : 2.6.9
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pytables : None
s3fs : None
scipy : 1.3.0
sqlalchemy : 1.3.6
tables : None
xarray : None
xlrd : 1.2.0
xlwt : None
xlsxwriter : None

[bergkvist]

Related issues:

• DataFrame.set_index() may not preserve dtype #30517
• BUG: Setting the index changes dtype #34304

Related PRs:

• BUG: Wrong dtype when resetting a multiindex with missing values. (#1… #27370

[jreback]

as you have noted this is a duplicate

we do not have a Uint32 index and this is the best that can be done now

[bergkvist]

What about expanding uint32 to int64 instead of uint64? That would solve my problem here: #34356