TST(string dtype): Resolve xfails in test_from_dummies

[rhshadrach]

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

The current behavior assumes the default_category provided can be coerced to the dtype of the input's columns. When the input's columns labels are strings, and the default_category is an integer, currently with object dtype we end up with values that are a mix of strings and integers. With infer_string=True where the input's columns are str dtype, we end up instead with all strings (coercing the integer to a string).

It's not clear to me whether this case should result in object dtype with a mix of strings and integers, or str dtype. Thoughts here are welcome. A few cases to consider are below. Currently I'm going with backwards compatibility, but open to other directions.

df = DataFrame({3: [1, 0, 0], 4: [0, 1, 0]})
result = pd.from_dummies(df, default_category=0.5)
# ValueError: Trying to coerce float values to integers

df = DataFrame({"x": [1, 0, 0], "y": [0, 1, 0]})
result = pd.from_dummies(df, default_category=5)
print(type(result.iloc[2, 0]))
# <class 'int'>

[rhshadrach]

@jorisvandenbossche @WillAyd friendly ping

[WillAyd]

The current behavior assumes the default_category provided can be coerced to the dtype of the input's columns. When the input's columns labels are strings, and the default_category is an integer, currently with object dtype we end up with values that are a mix of strings and integers. With infer_string=True where the input's columns are str dtype, we end up instead with all strings (coercing the integer to a string).

It's not clear to me whether this case should result in object dtype with a mix of strings and integers, or str dtype. Thoughts here are welcome. A few cases to consider are below. Currently I'm going with backwards compatibility, but open to other directions.

This is a tough one but I don't think we should do any special-casing in this method, so should just stick with what the different string types do (even though coercion may not be consistent)

[rhshadrach]

@WillAyd - coming back to this, what do you think of raising? Currently specifying a float when columns are integers raises. My desired behavior with strings would be the same: if you give an integer value and your columns are string dtypes, we should raise.

If we do agree that's what we want, I think we should hold off on this one until 3.0.

[WillAyd]

Yea generally I think its a good idea to be more strict about the data types, especially with the dedicated string type. So I'd be in favor of raising instead of coercing