Yes, this is a problem.
If we use self._encoder.transform, we'll need to fit self._encoder in fit.

If we use self._encoder.transform, we'll need to fit self._encoder in fit.

Yes, although I am not sure it's necessary because we pass the categories to the constructor so the _encoder should be stateless. To be investigated.

Yes, although I am not sure it's necessary because we pass the categories to the constructor so the _encoder should be stateless. To be investigated.

I think our OneHotEncoder can't transform without fit, even though we've provided it with sufficient information.

I'm wondering why this is not detected by the common test but I don't have time to investigate now. So contributors here please try to investigate our common test.

Hey, I'd like to work on this if no one else has taken it up yet!

An issue is never "taken" :) If you don't see any linked PR, feel free to give it a try. I am not sure that this is a good first issue though. In particular you need to be very familiar with the details of the contract of the estimator API: http://scikit-learn.org/stable/developers/contributing.html#apis-of-scikit-learn-objects

If we do fit_transform in transform, is there any need to store the encoder?

We also need it in inverse_transform, so I guess we still need to store it.

So there's actually a bug in our common test (i.e., we use .copy() instead of deepcopy to copy the dictionary). I've submitted a PR to fix that.

@ogrisel I eventually recall that we choose to fit the OneHotEncoder in transform because we only determine the bins in fit. We need to put data into different bins before feeding it to OneHotEncoder.
(1) The common test fail to detect it because we use .copy() to copy the dictionary (See #12514 (comment)).
(2) There's another bug here, we can't inverse_transform after fit.
(3) We can't fit the encoder in fit because we don't put data into different bins in fit.
(4) We need to store the encoder because we need it in inverse_transform.
I'm unable to figure out a good solution (maybe some code refactoring?)

FYI I proposed an awkward solution in #12514 without refactoring the code.

(2) There's another bug here, we can't inverse_transform after fit.

I don't understand what you mean here.

I don't understand what you mean here.

@ogrisel Previously, we'll get an error if we try something like (though maybe uncommon):

trans = KBinsDiscretizer()
trans.fit(...)
trans.inverse_transform(...)

because we fit the OneHotEncoder in transform. This will be fixed in #12514