BUG: Exception for ExtensionDtype with missing attributes not very helpful

[datapythonista]

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
from pandas.core.dtypes.dtypes import register_extension_dtype, PandasExtensionDtype

@register_extension_dtype
class FooType(PandasExtensionDtype):
    pass

series = pandas.Series([1, 2, 3], dtype='foo')

Issue Description

When implementing a pandas dtype, a name attribute is required for the class. When it's not present, the reported error is far from useful:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/mgarcia/src/pandas/pandas/core/series.py", line 386, in __init__
    dtype = self._validate_dtype(dtype)
  File "/home/mgarcia/src/pandas/pandas/core/generic.py", line 431, in _validate_dtype
    dtype = pandas_dtype(dtype)
  File "/home/mgarcia/src/pandas/pandas/core/dtypes/common.py", line 1770, in pandas_dtype
    result = registry.find(dtype)
  File "/home/mgarcia/src/pandas/pandas/core/dtypes/base.py", line 492, in find
    return dtype_type.construct_from_string(dtype)
  File "/home/mgarcia/src/pandas/pandas/core/dtypes/base.py", line 281, in construct_from_string
    assert isinstance(cls.name, str), (cls, type(cls.name))
AssertionError: (<class '__main__.FooType'>, <class 'property'>)

Expected Behavior

The example should raise an exception complaining of FooType missing a required name attribute.

Is there a reason why we aren't using an abstract class for ExtensionDtype with abstract methods for the required methods, instead of the lazy AbstractMethodError call? If we weren't about to instantiate the class, I'd understand, but looks like we're creating an instance. So, just the standard way of decorating the required methods as abstracmethod and making sure we create the instance before any use, would provide the expected behavior for free.

Installed Versions

import pandas
pandas.show_versions()

INSTALLED VERSIONS

commit : afc06e7
python : 3.10.2.final.0
python-bits : 64
OS : Linux
OS-release : 5.11.22-100.fc32.x86_64
Version : #1 SMP Wed May 19 18:58:25 UTC 2021
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_GB.UTF-8
LOCALE : en_GB.UTF-8

pandas : 1.5.0.dev0+385.gafc06e780e.dirty
numpy : 1.22.2
pytz : 2021.3
dateutil : 2.8.2
pip : 22.0.3
setuptools : None
Cython : None
pytest : 7.0.1
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
fastparquet : None
fsspec : None
gcsfs : None
markupsafe : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
zstandard : None

[jbrockmendel]

Looking at this and its tough. If we change from assert to just raising TypeError if it isnt implemented, then that gets caught by Registry.find and falls through, then in pandas_dtype the user actually gets

    npdtype = np.dtype(dtype)
              ^^^^^^^^^^^^^^^
TypeError: data type 'foo' not understood

I think @datapythonista is right that something at class-definition-time like abstractmethod would be ideal. Two other ideas that come to mind are 1) check in __init_subclass__, 2) add a test in the ExtensionTests so that at least implementors should get a heads-up if they missed it.