BUG: `Series.astype("object_")` and `Series.astype("object0")` unsupported.

[randolf-scholz]

Pandas version checks

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

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

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

Numpy has many aliases for its dtypes. I noticed that 2 of them are not working without any apparent reason:

import numpy as np
import pandas as pd

s = pd.Series([0, 1])

for key in np.sctypeDict:
    if not isinstance(key, str):
        continue
    try:
        s.astype(key)
    except:
        print(key)

returns

M
m
object0
M8
datetime64
m8
timedelta64
object_

Now all of the datetime/timedelta types (m/M) it makes sense that they are not supported as pandas requires a frequency parameter (s/ms/us/ns/...). However, it seems weird that both "object_" and "object0" are missing.

Issue Description

It is unclear why certain type-aliases are not supported.

Expected Behavior

both "object_" and "object0" should cast the series to dtype np.object_.

Installed Versions

INSTALLED VERSIONS
------------------
commit           : 0f437949513225922d851e9581723d82120684a6
python           : 3.11.3.final.0
python-bits      : 64
OS               : Linux
OS-release       : 5.19.0-46-generic
Version          : #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 21 15:35:31 UTC 2
machine          : x86_64
processor        : x86_64
byteorder        : little
LC_ALL           : None
LANG             : en_US.UTF-8
LOCALE           : en_US.UTF-8

pandas           : 2.0.3
numpy            : 1.24.3
pytz             : 2023.3
dateutil         : 2.8.2
setuptools       : 68.0.0
pip              : 23.2
Cython           : 0.29.36
pytest           : 7.4.0
hypothesis       : None
sphinx           : 7.0.1
blosc            : None
feather          : None
xlsxwriter       : None
lxml.etree       : 4.9.3
html5lib         : None
pymysql          : 1.4.6
psycopg2         : None
jinja2           : 3.1.2
IPython          : 8.14.0
pandas_datareader: None
bs4              : 4.12.2
bottleneck       : None
brotli           : None
fastparquet      : 2023.7.0
fsspec           : 2023.6.0
gcsfs            : None
matplotlib       : 3.7.2
numba            : 0.57.1
numexpr          : 2.8.4
odfpy            : None
openpyxl         : 3.1.2
pandas_gbq       : None
pyarrow          : 12.0.1
pyreadstat       : None
pyxlsb           : None
s3fs             : None
scipy            : 1.11.1
snappy           : None
sqlalchemy       : 1.4.49
tables           : 3.8.0
tabulate         : 0.9.0
xarray           : 2023.7.0
xlrd             : None
zstandard        : None
tzdata           : 2023.3
qtpy             : None
pyqt5            : None

[lithomas1]

np.object0 shouldn't be supported as it is deprecated.
numpy/numpy#22607

I guess "object_" should work given np.object_ does work.

Supporting it doesn't look hard, it's probably just a manner of changing this line to include "object_"

pandas/pandas/core/dtypes/common.py

Line 1637 in d2f05c2

if is_hashable(dtype) and dtype in [object, np.object_, "object", "O"]:

[Julian048]

take

[randolf-scholz]

@lithomas1 what about the other 0-ending types?

import numpy as np
{s for s in np.sctypeDict.keys() if isinstance(s, str) and s.endswith("0")}
>>> {'bytes0', 'int0', 'object0', 'str0', 'uint0', 'void0'}

Seems like either all of these should be supported or none of them for consistency.
For what's worth, it also seems that numpy does not raise a deprecation warning for the strings:

import numpy as np

a = np.array([1,2,3])
a.astype("int0")   # no DeprecationWarning
a.astype(np.int0)  # DeprecationWarning: `np.int0` is a deprecated alias for `np.intp`.

So either the numpy-team forgot the DeprecationWarning for "int0", or the string is still considered a valid alias for np.intp. (as of version 1.25.2)

[lithomas1]

Hm, that might have been intentional on numpy's part.

In the PR it says,

(Unfortunately, these are here still allowedas part of the np.sctypeDict).

Personally, I'd prefer to see the aliases all gone, but I don't care too much.

cc @seberg who did the deprecation

[seberg]

I can't see a good reason for int0 so it wouldn't hesitate to just delete it some time, it was an oversight for sure. I think we might just remove that dict completely in any case. Am I missing any reason why this should work?

[randolf-scholz]

@seberg Does numpy export a list of its recognized aliases in any other place? This is quite useful information to have, for example I used sctypeDict recently in pandas-stubs to check that all relevant literal type-aliases are covered by the stubs.

[seberg]

None of these lists are really nice, I think sctypeDict is probably the most canonical for being thorough. Maybe you can open a NumPy issue to create a more canonical list somewhere (maybe you even have a thought!)? Do you care if it is a bit minimal? In NumPy we sometimes omit things from stubs which we don't really want users to use (but also don't really want to delete).