BUG: Latest rc falls over with TypeError in _try_cast()

[pettersensz]

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

import pandas as pd
pd_float_64 = pd.Series([1.234], dtype=pd.Float64Dtype)

Issue Description

If I do the lines above in pandas 2.0.3 or earlier versions, there is no error.
If I do the same in pandas 2.1.0rc0 it will fail with a TypeError:
TypeError: 'in <string>' requires string as left operand, not pandas._libs.properties.CachedProperty

I also tried installing the development version, and the issue is also present there.

It seems this is related to the change on line 777 in pandas.core.construction.py
Changed from elif dtype.kind in ["m", "M"]: to elif dtype.kind in "mM":

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\****\Miniconda3\envs\testingenvironmentPreview\lib\site-packages\pandas\core\series.py", line 512, in __init__
    data = sanitize_array(data, index, dtype, copy)
  File "C:\Users\****\Miniconda3\envs\testingenvironmentPreview\lib\site-packages\pandas\core\construction.py", line 621, in sanitize_array
    subarr = _try_cast(data, dtype, copy)
  File "C:\Users\****\Miniconda3\envs\testingenvironmentPreview\lib\site-packages\pandas\core\construction.py", line 777, in _try_cast
    elif dtype.kind in "mM":
TypeError: 'in <string>' requires string as left operand, not pandas._libs.properties.CachedProperty

Expected Behavior

Expected it to work like before.

Installed Versions

INSTALLED VERSIONS

commit : 6e194cf
python : 3.9.17.final.0
python-bits : 64
OS : Windows
OS-release : 10
Version : 10.0.22621
machine : AMD64
processor : Intel64 Family 6 Model 158 Stepping 13, GenuineIntel
byteorder : little
LC_ALL : None
LANG : None
LOCALE : English_United Kingdom.1252

pandas : 2.1.0rc0
numpy : 1.26.0b1
pytz : 2023.3
dateutil : 2.8.2
setuptools : 68.0.0
pip : 23.2.1
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : None
pandas_datareader : None
bs4 : None
bottleneck : None
brotli : None
dataframe-api-compat: None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None

[lithomas1]

Hi,
I can confirm this happens on main.

I think #52387 should be the culprit
cc @jbrockmendel

[jbrockmendel]

I’m under the weather, will look at this more closely in a couple days. At first glance, the problem is that you are passing the dtype class and not the dtype instance. We either need to convert it to an instance or raise

[pettersensz]

I can confirm that passing an instance instead does not raise an error in the preview version:

import pandas as pd
pd_float_64 = pd.Series([1.234], dtype=pd.Float64Dtype())

[jbrockmendel]

A starting point would be the following edit in pandas_dtype:

     result = registry.find(dtype)
     if result is not None:
+        if not isinstance(result, ExtensionDtype):
+            # GH#31356 we have a subclass, not an instance
+            result = result()
         return result