API: more permissive conversion to StringDtype
State: closed

- [x] closes #31204
- [ ] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

This is a proposal to make using ``StringDtype`` more permissive and be usable inplace of ``dtype=str``.

ATM converting to StringDtype will only accept arrays that are ``str`` already, meaning you will often have to use ``astype(str).astype("string")`` to be sure not to get errors, which can be tedious. For example these fail in master and work in this PR:

```python
>>> pd.Series([1,2, np.nan], dtype="string")
0       1
1       2
2    <NA>
dtype: string
>>> pd.array([1,2, np.nan], dtype="string")
<StringArray>
['1', '2', <NA>]
Length: 3, dtype: string
>>> pd.Series([1,2, np.nan]).astype("string")
0     1.0
1     2.0
2    <NA>
dtype: string
>>> pd.Series([1,2, np.nan], dtype="Int64").astype("string")
0       1
1       2
2    <NA>
dtype: string
```

etc. now work. Previously the above all gave errors.

## The proposed solution:
``ExtensionArray._from_sequence`` is in master explicitly stated to expect a sequence of scalars of the *correct* type. This makes it not usable for type conversion.

I've therefore added a new ``ExtensionArray._from_sequence_of_any_type`` that accepts scalars of any type and may change the scalars to the correct type before passing them on to ``_from_sequence``. Currently it just routes everything through to ``ExtensionArray._from_sequence``, except in ``StringArray._from_sequence_of_any_type``, where it massages the input scalars into strings before passing them on.

Obviously tests and doc updates are still missing, but I would appreciate feedback if this solution looks ok and I'll add tests and doc updates if this is ok.

Labels:
name: Strings
description: String extension data type and string data
name: ExtensionArray
description: Extending pandas with custom dtypes or arrays.

Comments:
https://github.com/pandas-dev/pandas/issues/33254 has a discussion about the appropriate strictness of `_from_sequence`.
Ther doctest failures are very strange, it doesn't make sense that they're failing in my PR, but not in other PRs...

From the discussion in #33254 it looks like a dedicated ``_from_sequence_of_any_type`` would not be the consensus approach, but maybe push its content to ``_from_sequence`` and maybe add a ``_from_scalars``, but it's doesnt seem like the issue is resolved in the other discussion?

any comments on the current PR?
The implementation itself looks good to me. 
Awaiting resolution of the discussion in #33254, I think in principle we can already add this behaviour to ``_from_sequence``, it would at least fix the conversion issues we have right now.
I've updated the PR:
* Moved the new functionality to ``StringArray._from_sequence``
* added tests to ``BaseCastingTests.test_astype_string``
* made changes to make the tests pass
* updated docs.
* Added a ``dtype`` argument to ``Series.combine``.

The last bullet point is because of a situation where you combine two ``string`` Series and want the result to be in another extension dtype is very difficult to do in a inferred way. I think it's better and safer in those cases to just supply the desired dtype.

@topper-123 workflow related question: can you please not force-push, but just add new commits (and merge master for updating with master)? That makes it a lot easier to review what has been updated since a previous review (and ensures github's UI to help with this actually works)
Ok, no problem,  I’ll stop force-pushing. I thought that made the commits more tidy and easier to read, but if that’s wrong, I’ll make regular commits in the future.
Updated.
thanks @topper-123 very nice!