@rth I edited _tree and _root to tree_ and root_

To sum up my view: I think that tree_ and root_ should be private. I'm still OK with documenting these, but we should make clear that we don't guarantee backward compatibility.

To sum up my view: I think that tree_ and root_ should be private. I'm still OK with documenting these, but we should make clear that we don't guarantee backward compatibility.

Overall I agree. Though I now that those are public, I wonder if it's really worth changing them.

BTW, GradientBoostingClassifier.loss_, a LossFunction (will be private once the deprecation cycle finished in 0.23) is also affected.

A releated question is then more on how to support custom objects as input arguments and whether this should be mentioned in some way in the docstring.

For instance,

• we support custom callable metrics. That fairly straightforward.
• one step up in complexity is support of custom loss functions (putting aside whether we might want to do such thing for now). For instance, lighgbm accepts as loss a function returning tuple of gradient, hessian which is also manageable.
• the question is what should be done in more complicated cases (such as GLMs where we need to be able to compute 4+ quantities, but not all at the same time). For instance, in plot_tree we sidestep this by passing the whole DecisionTreeClassifier estimator and then get estimator.tree_ returning a private instance. We could accept a function returning a long tuple, but that would unpractical and computationally inefficient. Making the underlying object public could be one way to go, but I'm not sure if it's reason enough to do that. Or mentioning it in the documentation in some way, not sure.

Another instance that I found is the loss_function_ attribute of BaseSGD and all child classes. I'm not sure it make sense to expose these, even though they're not explicitly private, they are defined in sgd_fast.pyx. They're all undocumented classes.

from #14789 (comment)