@ogrisel, I end up with different shapes when I implement this with OneHotEncoder sparse.  Apologies for the hasty analysis below if incorrect.

Do we have a preference against changing shape unless a step is explicitly marketed as a feature selection?  We'd also need a get_support method, right?

On a related noted, it looks like OneHotEncoder doesn't have its `sparse` argument documented and has no get_support method either.

For example, with the make_circles data and a sample nose run:
```
AssertionError:
Arrays are not equal

(shapes (100, 238), (100, 261) mismatch)
```