@glemaitre thanks for the feedback, I will proceed with the fixes.
Is it ok to rewrite ndarray or None, shape (n_features,) as ndarray of shape (n_features,) or None?

Normally we have

xxx : ndarray of shape (n_features,) or None

If there is a default then

xxx: ndarray of shape (n_features,), default=None

Could you check the linter error

Hi @glemaitre, the linter errors are due to the line

        X : {array-like, sparse matrix, dataframe} of shape (n_samples, n_features)

being too long. Is there a standard way within scikit-learn to split the line?

I scanned all the scikit-learn modules and I found that dataframe is almost never mentioned, is it because it might be considered covered by array-like?

You can split using the backslack

X : {array-like, sparse matrix, dataframe} of shape \
        (n_samples, n_features)
    Whatever description

Preview of how it would look like:

    def fit(self, X, y=None):
        """Compute the mean and std to be used for later scaling.

        Parameters
        ----------
        X : {array-like, sparse matrix, dataframe} of shape \
                (n_samples, n_features)
            The data used to compute the mean and standard deviation
            used for later scaling along the features axis.

        y
            Ignored
        """

Do you have any comments/improvements?

Cool!

Another thing I noticed: some .transform() methods do not document the output. For instance:

Shall I fix it now, or it should be part of another issue/PR?

Let's correct this in the same PR then :) It will be a documentation change consistency across the file.

Hi @glemaitre, I did some last checks and everything seems good. What do you think?

Thanks for the suggestions, I will work on it tomorrow!

Is there a standard way to document a list with a fixed type of its elements?
For instance:

input_features : list of str, length n_features, default=None

You were probably aware of this, but I found out a way to set a template for the documentation: https://github.com/NilsJPWerner/autoDocstring/blob/master/src/docstring/templates/numpy.mustache

I do not think we should add dataframe everywhere. It would fit almost everywhere we have ndarray as long as np.asarray returns a a homogeneous ndarray.

I do not think if we should add dataframe everywhere. It would fit almost everywhere we have ndarray as long as np.asarray returns a a homogeneous ndarray.

I would prefer to be explicit and mention it.

On one hand, I see that dataframe is almost never explicitly mentioned in sklearn, but I see here https://scikit-learn.org/stable/developers/contributing.html#contribute-documentation that it's given as an option

Up to now, our dev guide states {array-like, sparse matrix, dataframe}.
I don't mind that we come with something shorter and change the guideline.

However, I really feel that we should settle with those once for all. It is bad that we ask contributors to add/remove at each new reviewer passing by while the dev guide should be sufficient regarding the doc style.

However, I really feel that we should settle with those once for all. It is bad that we ask contributors to add/remove at each new reviewer passing by while the dev guide should be sufficient regarding the doc style.

We can talk about this in the monthly call.

Here are my thoughts:

It looks like we only use dataframe in the column transformer, some mixins, and the return types of the dataset functions.

I would say unless we are doing something special with the column names, we just need "array-like". If we are doing something special, such as in column transformer, we can put "dataframe" or maybe "frame-like" (if a dataframe protocol becomes a thing).

In the end, I want to avoid listing out every single valid data structure. Currently, we can take cupy arrays, dask arrays, xarrays, etc. and they work because they are "array-like". This can get incredibility verbose if we list them all.

I think I agree with your point. Until an estimator uses a DataFrame as an array, then we can consider in the array-like. Right now, we only state that DataFrame should be numeric to be an array-like but actually we could consider object dtype, if the estimator can manage the data (OHE or OrdinalEncoder for instance).

I am also thinking that we should be careful with the output type. Usually, if an array or sparse array is given, we will output the same type. It is one of the reasons that I might not consider stating dataframe since we cannot output them up to now. And as you mentioned, if we grow support for these different types and we need to state types in input and output, it needs to be done wisely to avoid verbosity.

I will remove the references to dataframe then.

Thanks @Alemaudit, #17359 bring more light on the dataframe and as you did here, we will not it in the description. I will have a quick look but I think that I should be able to merge.

Thanks @Alemaudit for the patience :)

Thanks @glemaitre, it was a pleasure to contribute!