BUG: to_numeric() raises TypeError for StringDtype series

[RauliRuohonen]

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Code Sample, a copy-pastable example

import pandas as pd
pd.to_numeric(pd.Series(['1', None, '2'], dtype='string'))

Problem description

Running this code results in TypeError: Invalid object type at position 1

The same code works for old-style str dtype. Running

import pandas as pd
pd.to_numeric(pd.Series(['1', None, '2'], dtype='str'))

outputs

0    1.0
1    NaN
2    2.0
dtype: float64

This is a common way to convert strings to floats, and switching from the old-style 'str' to the new-style 'string' dtype will break code using it.

Expected Output

0    1.0
1    NaN
2    2.0
dtype: float64

Output of pd.show_versions()

INSTALLED VERSIONS

commit : db08276
python : 3.8.2.final.0
python-bits : 64
OS : Darwin
OS-release : 18.7.0
Version : Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.1.3
numpy : 1.18.5
pytz : 2020.1
dateutil : 2.8.1
pip : 19.2.3
setuptools : 41.2.0
Cython : 0.29.21
pytest : 6.1.1
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 2.11.2
IPython : 7.15.0
pandas_datareader: None
bs4 : None
bottleneck : None
fsspec : None
fastparquet : 0.4.1
gcsfs : None
matplotlib : 3.2.2
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 0.17.1
pytables : None
pyxlsb : None
s3fs : None
scipy : 1.4.1
sqlalchemy : 1.3.19
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
numba : 0.50.0

Output of pd.show_versions() (master)

INSTALLED VERSIONS

commit : c15ded3
python : 3.8.2.final.0
python-bits : 64
OS : Darwin
OS-release : 18.7.0
Version : Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.2.0.dev0+829.gc15ded3ed
numpy : 1.18.5
pytz : 2020.1
dateutil : 2.8.1
pip : 19.2.3
setuptools : 41.2.0
Cython : 0.29.21
pytest : 6.1.1
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 2.11.2
IPython : 7.15.0
pandas_datareader: None
bs4 : None
bottleneck : None
fsspec : None
fastparquet : 0.4.1
gcsfs : None
matplotlib : 3.2.2
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 0.17.1
pyxlsb : None
s3fs : None
scipy : 1.4.1
sqlalchemy : 1.3.19
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
numba : 0.50.0

[dsaxton]

For now probably makes sense to cast this to float64 with NaN, but should this eventually convert to a nullable Int64 or Float64 @jorisvandenbossche?

[jorisvandenbossche]

Yes, if the input is a new string dtype, then it should return nullable int or float

[RauliRuohonen]

Oops, I meant to write

import pandas as pd
pd.to_numeric(pd.Series(['1.0', None, '2.0'], dtype='string'))

as the example, to ensure that the result should be float (this code produces TypeError, too). With the code I did give,

import pandas as pd
pd.to_numeric(pd.Series(['1', None, '2'], dtype='string'))

it should of course produce Int64, because without None it produces int64, so the "Expected Output" section I wrote is incorrect in that regard.

[jorisvandenbossche]

For reference, the follow up issue to fix it properly is at #37294