LabelEncoder with mixed typed labels feature or bug?

[thomasjpfan]

Is the following a bug or a feature?

from sklearn.preprocessing import LabelEncoder

LabelEncoder().fit_transform(['1', '2', 2])
# array([0, 1, 1])

LabelEncoder().fit_transform(np.array(['1', '2', 2]))
# array([0, 1, 1])

LabelEncoder().fit_transform(np.array(['1', '2', 2], dtype=object))
# TypeError: Encoders require their input to be uniformly strings or numbers.

This stems from how we only check for multiple types in _encode when dtype=object. Note this behavior is the same in 0.22, 0.23, and on master.

[amueller]

For the center we have no choice, the bottom one makes sense to me, you don't want to necessarily identify '1' with 1.
You might argue that the top one is a bug, but I'm not sure if we want to replace the numpy casting logic.

Btw, you run into this when concatenating dataframes from multiple csv files and a column is sometimes parsed as string and sometimes as integer. Great Fun!

[jnothman]

No this stems from numpy casting issues when an array is constructed with string elements.

[jnothman]

Or are you saying that we should have a check_array that is more clever about mixed types in non-array input?

[glemaitre]

If we want to make the stuff consistent I am really scared that we will stumble in the dtype nightmare and we might come with tricks-and-tips implementations on something which should already be solved otherwise I think.

If we could maybe have better error messages with potential avenues for resolution could already be great.