I find it weird to have a sub-class of TransformerMixin without a transform method. But maybe it's better than what we do currently...

Since the Mixin only defines fit_transform and we override it, I find it fine to inherit.

The problem we are trying to solve by inheriting is having TSNE selected as a transformer by all_estimators. Is there another way of doing that, other than having to inherit from TransformerMixin?

It feels weird to inherit, which for me is saying "I am a transformer with all the things a transformer can do!" and then not have a transform method. But the mixin doesn't define it either. So is having a transform method not part of being "a real transformer"?

On a pragmatic level, using the mixin is a nice way to get into the list of all_estimators and maybe mixins aren't like real "is a" style inheritance?

"I am a transformer with all the things a transformer can do!"

Looking at the documentation, it seems that the original spirit is indeed to have at least fit and transform and fit_transform is just a convenience.

On a pragmatic level, using the mixin is a nice way to get into the list of all_estimators and maybe mixins aren't like real "is a" style inheritance?

We could always replace by duck-typing: if an estimator implements fit+transform or/and fit_transform, then it should pass the test of a transformer.
Indeed, some of our checks are ducktyping while the helper to list the estimators is checking for the mixins.

Actually, the annoying part with duck-typing is that we already need to have an instance while we are playing with classes at this stage.

I don't quite understand what you mean. To find out if a method is implemented you could do something like "fit" in dir(Estimator) no?

Indeed we could. I just had in my mind a piece of the parameter validation framework HasMethods that does this job already for instances.