Advanced API
See original GitHub issueIn a few places we’ve mentioned certain functions which we would like to have, but they don’t necessarily fit the usual fit/transform/predict pattern.
For instance, @jnothman mentioned having an add function for the ColumnTransformer, which we can also have for the Pipeline.
We also talked about a prune_tree function in #14038.
One concern seems to be that we would like to keep the API very simple and easy, which I agree with. But it doesn’t have to limit us from having more ad-hoc functions, which we could fit in a separate section in the docs and tag them as advanced.
I’m not sure how we could handle that with sphinx, but what I’m proposing is to tag those functions as advanced, and have sphinx render them in an “advanced” section bellow the other functions. This way they would not interfere with the usual experience of a new user who’s reading the docs, and yet it would enable us to introduce some rather useful methods.
I may be missing some historical discussion on this topic though, sorry for that.
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (9 by maintainers)

Top Related StackOverflow Question
In ColumnTransformer the benefit of ‘add’ is that it gets rid of the need to remember the order of a triple because the method has parameter names. It means that you can specify or use the default name for a step, rather than the all-or-nothing approach of make_pipeline vs Pipeline. It would make it easier to integrate other ways for users to specify the set of columns too.
Thanks for the clarification, that wasn’t clear to me from the initial description. I’m +0 on an
addmethod right not, I think. I haven’t found this to be an inconvenience so far.