to_string() does not have an "encoding" parameter.

[mohitanand001]

Code Sample, a copy-pastable example if possible

df = pd.DataFrame(data = {'Japanese' : 'こんにちは', 'English' : 'Hello'}, index = [0])
df.to_string()

Output of pd.show_versions()

[paste the output of pd.show_versions() here below this line]
INSTALLED VERSIONS

commit : None
python : 3.7.1.final.0
python-bits : 64
OS : Windows
OS-release : 10
machine : AMD64
processor : Intel64 Family 6 Model 78 Stepping 3, GenuineIntel
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.None

pandas : 0.25.0
numpy : 1.16.2
pytz : 2018.7
dateutil : 2.7.5
pip : 18.1
setuptools : 40.6.3
Cython : 0.29.2
pytest : 4.0.2
hypothesis : None
sphinx : 1.8.2
blosc : None
feather : 0.4.0
xlsxwriter : 1.1.2
lxml.etree : 4.2.5
html5lib : 1.0.1
pymysql : None
psycopg2 : 2.8.3 (dt dec pq3 ext lo64)
jinja2 : 2.10
IPython : 7.2.0
pandas_datareader: None
bs4 : 4.6.3
bottleneck : 1.2.1
fastparquet : None
gcsfs : None
lxml.etree : 4.2.5
matplotlib : 3.0.2
numexpr : 2.6.8
odfpy : None
openpyxl : 2.5.12
pandas_gbq : None
pyarrow : 0.13.0
pytables : None
s3fs : None
scipy : 1.1.0
sqlalchemy : 1.2.15
tables : 3.4.4
xarray : None
xlrd : 1.2.0
xlwt : 1.3.0
xlsxwriter : 1.1.2

[mroeschke]

Can you give an example of the expected behavior and API parameters?

[mohitanand001]

Just like to_csv() and to_excel() have an "encoding" parameters, we can have an encoding parameter in string for consistency.

df.to_string(encoding = "iso-8859-1")

[WillAyd]

Might not be thinking straight today but wouldn't this only make sense if it were a to_bytes method? Not applicable for to_string, no?

[TomAugspurger]

Agreed with Will. An encoding is only necessary when going between strings and bytes. But we're converting from a Python object to a string.

…

On Thu, Oct 3, 2019 at 4:43 PM William Ayd ***@***.***> wrote: Might not be thinking straight today but wouldn't this only make sense if it were a to_bytes method? Not applicable for to_string, no? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#28766?email_source=notifications&email_token=AAKAOITGN7FSSWSDBQQ27R3QMZRRPA5CNFSM4I46HERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJWDTQ#issuecomment-538141134>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKAOIVF6V2DFWHXZPJ7MYLQMZRRPANCNFSM4I46HERA> .

[mohitanand001]

#28663 (comment)

the to_html method has no encoding. I assume that it is fairly simple to work-around by passing an open buffer with the correct encoding or not passing a filepath, and writing the return unicode string to file using the appropriate encoding?

the buffer handling code is shared with to_latex and to_string. to_latex already has an encoding parameter and the shared code can handle encoding. so it should be straightforward to add encoding to to_html ( and to_string) for consistency.
#15008 (comment) "Textual payloads should support the encoding argument"

[TomAugspurger]

Forgot about the buf argument accepting a string path.

In that case, accepting an encoding makes sense, for specifying the encoding for the newly created file. We should raise when encoding is specified and it's buf isn't a string path.