TST: Review if we are really testing with different locales

[datapythonista]

In the scripts for the CI, we set the locale with:

export LC_ALL="$LOCALE_OVERRIDE";
export LANG="$LOCALE_OVERRIDE";

and immediately later we display the locale detected by pandas:

pycmd='import pandas; print("pandas detected console encoding: %s" % pandas.get_option("display.encoding"))'
python -c "$pycmd"

(see https://github.com/pandas-dev/pandas/blob/master/ci/script_single.sh#L5)

Checking the logs, I can see how in the two builds where we specify locales, the output is:

# Linux py37_locale
2018-11-25T20:35:30.0051096Z Setting LC_ALL and LANG to zh_CN.UTF-8
2018-11-25T20:35:31.0423116Z pandas detected console encoding: UTF-8

and

# Linux py36_locale_slow
2018-11-25T20:37:45.3938178Z Setting LC_ALL and LANG to it_IT.UTF-8
2018-11-25T20:37:46.4791772Z pandas detected console encoding: UTF-8

And also in Travis:

# 2.7, locale, slow, old NumPy
Setting LC_ALL and LANG to zh_CN.UTF-8
pandas detected console encoding: UTF-8

I checked the logs for the PR #23908 but I assume all are the same.

If I'm not misunderstanding anything, I think pandas is not detecting the locale we want to test with, and it's testing with the default UTF8 locale, as in the rest of the tests.

CC: @jreback @TomAugspurger

[jreback]

https://travis-ci.org/pandas-dev/pandas/jobs/459490848

looks ok to me

[datapythonista]

not sure I understand. Isn't pandas.get_option("display.encoding") expected to output zh_CN.UTF-8 in that travis job? In line 1805 of the link you provided is returning UTF-8 instead.

[gfyoung]

@datapythonista : I know it's been a couple of months since there was chatter in this issue, but do you mind checking the most recent master builds?

I took a glance, and I didn't see the locale complaints that you were seeing before...

[datapythonista]

I think this was working well in travis, where one of the set up scripts was editing the pandas __init__.py and changing the locale there. But that wasn't implemented in Azure (or CircleCI before), where only the environment variable was defined.

This is unified in #24632. And should work after this is merged. Thanks for pointing out, I'll add this issue there, so it gets automatically closed.