Thanks. It would be nice not to require a download, or at least not custom parsing code. But I'm not sure that's realistic. I'm not sure if we want to allow pandas in the examples but we could also just do a pd.read_csv to an URL, of, say, titanic. That would also give an opportunity to show the typical extraction of the labels from a dataframe.

@amueller I searched in the sklearn.datasets and the only dataset that I saw with mixed types was Boston housing, but the categorical feature was already encoded. So load from URL was the best thing I could think about.

Regarding the use of pandas, I found numpy not very elegant to hold string and float data, furthermore, not using pandas blocks us from demonstrating the true power of using sklearn.compose.make_column_transformer with column names.

I will procede then to refactor the example using pd.read_csv to a conventional URL, e.g. titanic.

I think that's a good idea, and yes, there's no dataset loader for a dataset with mixed features right now. fetch_openml will provide that "soon".

I've changed the example.
Here ColumnTransformer takes 2 preprocessing pipelines (for both categorical and numerical data).
I also implemented a custom imputer for categorical data that is used in the mentioned pipeline.

To go straight to the point with the usage of ColumnTransformer I performed a train-test split and evaluated the model directly with default params. I avoided hyperparameter tuning (grid search, ...) to not clog up excessively the example.

I am surprised CustomCategoryImputer is not something we already have.
I might be out of the loop, but if we don't have it, I think we should, maybe in SimpleImputer with a new strategy (strategy='fixed'), or inside CategoricalEncoder (or its re-factored version in #10523).

@TomDLT I have checked the imputers in sklearn.impute (including SimpleImputer) and only numerical types are supported (strategy={'mean', 'median', 'most_frequent}).

Setting handle_unknown='ignore' in CategoricalEncoder allows to return all zeros when unseen categories are encountered when transforming, but yet it can't handle np.nan (even during fit).

Yes, the inability to handle missing values with categorical data (both in SimpleImputer and CategoricalEncoder )is a know problem, which we hope to fix at least with a basic solution before the release. We were discussing this yesterday, and were also thinking of adding a 'constant'/'fixed' strategy for SimpleImputer.
But until then, the custom transformer here is fine I think (although it distracts from the actual example), then we can later simply replace it with the built-in solution.

@jorisvandenbossche I agree it could distract a bit from the core matter of the example, but I thought it was interesting to include it in order to use a Pipeline for the categorical data inside ColumnTransformer.

The alternative solution would have been to use pandas' dropna on the categorical subset at the beginning of the script, and just apply CategoricalEncoder.

Also, I am tempted to extend the example a bit more and include a hyperparameter optimization with grid search for instance, in order to demonstrate how to access the parameters within a ColumnTransformer. I'll try to do this later on today.

Any further thoughts?

The alternative solution would have been to use pandas' dropna on the categorical subset at the beginning of the script, and just apply CategoricalEncoder.

Alternative pandas solution would also be to fillna('missing') on the categorical columns (which would be equivalent to your custom transformer).
Anyhow, I don't think this is too important, as we plan to replace this part with a SimpleImputer in the short term.

Also, I am tempted to extend the example a bit more and include a hyperparameter optimization with grid search

I commented just the same, so yes, I think that's a good idea :-)
I did a small GridSearchCV in my example here https://jorisvandenbossche.github.io/blog/2018/05/28/scikit-learn-columntransformer/#Using-our-pipeline-in-a-grid-search

One other suggestion, certainly if you would make the example longer, is to use the typical sphinx gallery syntax to alternate code and text blocks, see eg in https://github.com/scikit-learn/scikit-learn/blob/master/examples/plot_compare_reduction.py

Alternative pandas solution would also be to fillna('missing') on the categorical columns (which would be equivalent to your custom transformer).

True. Should we go for this then?

I commented just the same, so yes, I think that's a good idea :-)
I did a small GridSearchCV in my example here https://jorisvandenbossche.github.io/blog/2018/05/28/scikit-learn-columntransformer/#Using-our-pipeline-in-a-grid-search

Will go for it! Thanks for the link!!

One other suggestion, certainly if you would make the example longer, is to use the typical sphinx gallery syntax to alternate code and text blocks, see eg in https://github.com/scikit-learn/scikit-learn/blob/master/examples/plot_compare_reduction.py

Great! I'll use this. I was starting to worry about all the # comment lines I would have to use :)

Many thanks for the feedback @jorisvandenbossche ! I'll incorporate these changes.

Either at the top or in a comment, you should describe the nature of the features: are they numeric representations of category, or strings with how many values?

Why can't we do mode imputation in a pipeline on the categorical features after an ordinal encoding? It's a bit ugly, but it's not so bad...

Either at the top or in a comment, you should describe the nature of the features: are they numeric representations of category, or strings with how many values?

Will do.

Why can't we do mode imputation in a pipeline on the categorical features after an ordinal encoding? It's a bit ugly, but it's not so bad...

You mean?: use LabelEncoder as 1st step before one-hot encoding. I am aware we might be abusing the original intention of the label encoder, but it would already handle implicitly the imputing (It would be equivalent to imputing a fixed value) . E.g.:

import numpy as np
from sklearn.preprocessing import LabelEncoder
le = LabelEncoder()
le.fit(['a','b',np.nan,'c'])
le.transform([np.nan, 'b', 'c', 'a', np.nan])
>>>  array([3, 1, 2, 0, 3])

The output from this tranformer can directly jump into the CategoricalEncoder.
@jnothman @jorisvandenbossche what do you think of this?

This example should be referenced in place of hetero_feature_union at the
end of doc/faq.rst​

Woud this mean just substituting :ref:sphx_glr_auto_examples_hetero_feature_union.py for :ref:sphx_glr_auto_column_transformer_mixed_types.py?

You mean?: use LabelEncoder as 1st step before one-hot encoding

No, @jnothman meant to use CategoricalEncoder(encoding='ordinal') (the new non-abusive version of LabelEncoder for features :-))

Personally I would just leave it like it is for now. The intent is that SimpleImputer(strategy='constant') will be available before the release, and then we can use that in this example (which results in a separate category for 'missing').

This example should be referenced in place of hetero_feature_union at the
end of doc/faq.rst​

You can also add this example to the list of examples in the section on ColumnTransformer in compose.rst

looks good apart from nitpicks (and sorry about individual comments). I think the barrage of underscores in the grid-search is telling. But I'm happy we can finally actually do this!

@amueller thank you for the feedback!! I've changed the example based on your comments. Additionally, I've tried to make a better intro, I wasn't fully happy with it either.

There were conflicts with a recent merge to master: I have moved the example (and its references) under the compose folder.

Updated with your comments :)

Looks good, pending improvements to Imputer (perhaps #11211) and to ColumnTransformer (#11190)

@jnothman do you want to merge those PRs first so this example can be updated?

I think this PR is ready to be merged, so I would do that and then those other PRs can update the example.

Thanks @partmor

Thanks @partmor

Thank you all for your guidance and patience @jnothman @jorisvandenbossche @amueller @ogrisel !!!
This is my first contribution ever to a big open source project!! this only encourages me to keep going!!!
Thanks again!

Looks good, pending improvements to Imputer (perhaps #11211) and to ColumnTransformer (#11190)

I'll stay tuned to when strategy='constant' is implemented in SimpleImputer, and make a PR to include it in the example.

sorry Joris, i didn't see your comment. I don't see anything wrong with updating those PRs (though one isn't a PR yet) instead of waiting on them.

No problem, you already did exactly what I was suggesting in the meantime :-)

Thanks @partmor!

Question here: will it be better to put the data under scikit-learn/examples-data?
(1) It seems bit strange to fetch data from other's repo (though I respect amueller, one of our leaders)
(2) It's good for scikit-learn to have a dataset with missing data and string-encoded categorical variables (see #8888)
(3) We can also provide users with the source and some basic information of the data in the same repo.

I think the idea is that the (future) openml loader will provide such datasets (instead of keep adding new single datasets to sklearn for each use case, although a heterogeneous dataset with missing values is of course an important use case ..)

I think the idea is that the (future) openml loader will provide such datasets

That's fine. Thanks a lot for the instant feedback :)

Yeah it's weird to use my repo, I totally agree. Hopefully we can get rid of that soon. We could just ship the csv without a loader to use in examples (because CSV is such a common format) but that seems slightly strange?
Having an example that contains the boilerplate for separating a target from the data seems very helpful to me. Most data that I worked with required that, but none of our examples require that.