we have models that don't have transform, like TSNE. I think they don't inherit from TransformerMixin - if you can't transform, you're not a transformer.

if you can't transform, you're not a transformer.

In that case, should we remove similar checks that are already in there? e.g. https://github.com/scikit-learn/scikit-learn/blob/master/sklearn/utils/estimator_checks.py#L578

hm ok that is indeed inconsistent. I'm just a bit confused that we are not running into any troubles in master.

I believe it's because we're explicitly leaving out by name the transformers that don't have a transform method: https://github.com/scikit-learn/scikit-learn/blob/master/sklearn/utils/estimator_checks.py#L180

This, of course, doesn't help third-party estimators that we'd like to exclude as well.

All the exceptions by name have to go!

On 9 March 2016 at 10:32, Jake Vanderplas notifications@github.com wrote:

I believe it's because we're explicitly leaving out by name the
transformers that don't have a transform method:
https://github.com/scikit-learn/scikit-learn/blob/master/sklearn/utils/estimator_checks.py#L180

This, of course, doesn't help third-party estimators that we'd like to
exclude as well.

—
Reply to this email directly or view it on GitHub
#6510 (comment)
.

This solution LGTM, but I would like a comment that "may have fit_transform but not transform"

I still think that a transformer needs a transform method. Unfortunately it's unclear to me now what exception @jakevdp pointed to because line-numbers move :-/
All exceptions by name are gone in #8022

@jnothman yes TSNE is not a transformer ;)

I still think that a transformer needs a transform method

Closing this issue from 2016 due to reviewer disagreement about this being the right solution. Currently, a better way of achieving this would probably involve estimator tags.