String dtype: more informative repr (keeping brief __str__)

[jorisvandenbossche]

Attempt to address #59342

With the current version of the PR, the reprs for the different dtype variants are:

# default NaN variants
<StringDtype(na_value=nan)>
<StringDtype(storage='python', na_value=nan)>
# nullable NA variants
<StringDtype(na_value=<NA>)>
<StringDtype(storage='python', na_value=<NA>)>

Some questions to decide on:

• Do we use surrounding <...> or not? (we are somewhat inconsistent internally for similar reprs; e.g. the Index repr does not use it, the ExtensionArray repr does)
  • Including the <..> makes it clearer that it is not necessarily exactly executable code, I think
• Do we keep the current __str__ as is (i.e. just "str" or "string"), or do we include the storage for the "string" case (to preserve the current repr behaviour). i.e. make it to have the options "str", "string[pyarrow]" or "string[python]".
  • Essentially, this comes down to changing the dtype.name attribute or not (which right now is defined to be "str" or "string")
  • As comparison, for DatetimeTZDtype we do include the [] parametrization in .name (e.g. "datetime64[s, UTC]"), while for CategoricalDtype we do not (there it is just "category")
  • If we don't use it in the name/str, we actually never show "string[python]", while we still allow that as string alias for dtype arguments (e.g. in constructors or in astype())
• Currently I just use their own repr for pd.NA and np.nan, which means they are displayed as <NA> and nan
  • But we could also make it to look like pd.NA and np.nan. This makes it a more "executable" repr, which could be nice, but on the other hand I also don't want to encourage that too much.