✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: 58689a0. Link to the linter CI: here}

Thanks for the fix @MarcoGorelli!

It kind of feels like this is geting more and more complicated though 😅 ... see below for some issues I can imagine.

I was wondering why after all the strategy of creating an array and use the automatic dtype was dropped?

I guess one of the reason was in @thomasjpfan #28352 (comment) you said:

(Scikit-learn does not really like using fixed length string dtypes "<U4", so using object here keeps the original behavior.)

Is there anything else? If that's the only reason, maybe we can do .astype(object) if the automatically inferred dtype is a string dtype? I guess that makes a copy, not sure how crucial this is ...

I think the underlying issue is that np.result_type is a bit ambiguous: it can take both dtype-like objects (OrdinalEncoder(), 'float64', np.int32) and values (3.2, np.array([1, 2], dtype=np.float64), ...) see numpy/numpy#26612 (comment) for a proposed way to make this more explicit.

Here are some possible issues I can imagine with the code as it is in this PR:

• at one point, the warning will turn into an error:

  import numpy as np
  from sklearn.preprocessing import OrdinalEncoder
  
  np.result_type(OrdinalEncoder(), OrdinalEncoder())

  For completeness the warning is:

  <ipython-input-1-5c4a0f627be2>:4: DeprecationWarning: in the future the `.dtype` attribute of a given datatype object must be a valid dtype instance. `data_type.dtype` may need to be coerced using `np.dtype(data_type.dtype)`. (Deprecated NumPy 1.20)
  

  The reason for the warning is that OrdinalEncoder().dtype is np.float64 and not np.dtype(np.float64)

• you could imagine some other edge cases, e.g. you do a grid-search on OrdinalEncoder dtype so the values could be like things like ['float64', 'float32']. You would expect the dtype to be object, except that:

  np.result_type('float64', 'float32') # dtype('float64') not object

thanks!

I was wondering why after all the strategy of creating an array and use the automatic dtype was dropped?

another issue is that then, a list of tuples would be detected as a 2D array instead of an object 1D array of tuples

at one point, the warning will turn into an error:

true, but TypeError, ValueError are already caught - hopefully that'll catch whatever error this turns into too? 🤞

Good points indeed, oh well I guess I don't a better solution so let's say it is OK enough for now.

If there is another bug found in this slightly tricky code we can at least think about moving the code to a function that can be more easily tested with edge cases.

another issue is that then, a list of tuples would be detected as a 2D array instead of an object 1D array of tuples

Indeed, I have seen you added a test for this in #28571 so 👍.

About the warnings that will maybe one day turn into an error in numpy, I guess our scipy-dev CI (testing our dependencies development version) will detect it in case this is neither TypeError ValueError and then we can ask Numpy to consider chosing an exception that does not break our (slightly brittle) code.