CLN: Don't use astype_nansafe after to_numpy

[dsaxton]

I'm not 100% sure about the change in the tests, but it seems to align with numpy:

[ins] In [1]: np.array([1, 2]).astype(str)                                                                                                                                                                   
Out[1]: array(['1', '2'], dtype='<U21')

[ins] In [2]: pd.array([1, 2]).astype(str)                                                                                                                                                                   
Out[2]: array(['1', '2'], dtype='<U21')

[ins] In [1]: np.array([True, False]).astype(str)                                                                                                                                                            
Out[1]: array(['True', 'False'], dtype='<U5')

[ins] In [2]: pd.array([True, False]).astype(str)                                                                                                                                                            
Out[2]: array(['True', 'False'], dtype='<U5')

[jorisvandenbossche]

Personally, I think those rather should convert to StringArray

[dsaxton]

Personally, I think those rather should convert to StringArray

Interesting idea, that does seem better

[jreback]

Personally, I think those rather should convert to StringArray

not at all, str conversion here is NOT the same as string.

[jreback]

@dsaxton can you merge master

[jorisvandenbossche]

not at all, str conversion here is NOT the same as string.

That's true. So in pandas, we generally see astype(str) or dtype=str as converting to strings *as object dtype. But that's not what this PR is doing. So the question is whether we want to be consistent with numpy (convert to numpy string dtype), or consistent with pandas (convert to string as object dtype).

But so, I personally think we can already interpret str to mean StringDtype if the array you start with is already using a nullable dtype (it's one thing less to deprecate in the future, and it's not a backwards incompatible change since StringDtype is opt-in anways).

[jreback]

not at all, str conversion here is NOT the same as string.

That's true. So in pandas, we generally see astype(str) or dtype=str as converting to strings *as object dtype. But that's not what this PR is doing. So the question is whether we want to be consistent with numpy (convert to numpy string dtype), or consistent with pandas (convert to string as object dtype).

But so, I personally think we can already interpret str to mean StringDtype if the array you start with is already using a nullable dtype (it's one thing less to deprecate in the future, and it's not a backwards incompatible change since StringDtype is opt-in anways).

I disagree, we always have str to mean string / object, NEVER string. I think changing this is way out of scope; changing for nullable types is VERY confusing. so -1 on this.

[jorisvandenbossche]

we always have str to mean string / object,

Which is also not what this PR is doing ...