Have `pd.array` infer new extension types

[TomAugspurger]

Currently pd.array sometimes requires an explicit dtype=... to get one of our extension arrays (we'll infer for Period, Datetime, and Interval).

This proposal is to have it infer the extension type for

• strings -> StringArray
• boolean -> BooleanArray
• integer -> IntegerArray

All of these currently return PandasArray.

Concretely, we'll need to teach infer_dtype how not to infer mixed for a mix of strings / booleans and NA values, similar to how it handles integer-na

In [27]: lib.infer_dtype([True, None], skipna=False)
Out[27]: 'mixed'

In [28]: lib.infer_dtype(['a', None], skipna=False)
Out[28]: 'mixed'

In [29]: lib.infer_dtype([0, np.nan], skipna=False)
Out[29]: 'integer-na'

and then handle those in array.

[jorisvandenbossche]

Concretely, we'll need to teach infer_dtype how not to infer mixed for a mix of strings / booleans and NA values, similar to how it handles integer-na

Shouldn't we infer with skipna=True ? (since all those new dtypes can hold missing values, we should ignore missing values when inferring?)

Another thought: should we add a keyword for this? (something like use_new_dtypes=True but with a potentially better name?) So if we would like to start using pd.array(..) more internally for array creation, we can still turn it off if needed.

[batterseapower]

If I might ask, what was the reasoning behind using the extension dtypes even if the input does not contain nulls? e.g. in 1.1.3 now str(pd.array([True, False]).dtype) == 'boolean', which means .values can't necessarily be used with numpy/numba since it's an extension array which those packages will not understand. Sorry if this has been discussed elsewhere but I couldn't find it: the changelog describes the change but doesn't really explain it.