Realistically, this should be in 0.23. We already have too much on our plate, I think.

I think they are clear for PCA's components, for Pipeline's steps, and for GridSearchCV's estimator and parameter grid.

I'm wondering whether it's easy to decide which patameters should be positional, e.g., do we think PCA(2) is reasonable? At least I don't like it.

And how shall we make the decision? I guess we don't want to open a vote for every class/function, right? So is +2 enough, or do we need +3?

e.g., do we think PCA(2) is reasonable? At least I don't like it.

It's about leaving some of this to the user discretion, or forcing them to use what we think best. Yes, PCA(2) is bad, while PCA(n_components) is reasonable. At least I wouldn't object to a PR using it, would you? Users can resent a limitation of their freedom (when to use or not position args) in cases when what there is no overwhelming reason for it.

So is +2 enough, or do we need +3?

I would say +2 since the SLEP was accepted but wait at bit before merging to give the possibility for feedback?

At least I wouldn't object to a PR using it, would you?

I don't like it but I'm not opposed to it.

Users can resent a limitation of their freedom (when to use or not position args) in cases when what there is no overwhelming reason for it.

Hmm, not sure, but the SLEP is passed?

At least I wouldn't object to a PR using it, would you?

I don't like it but I'm not opposed to it.

Let's put in another way. As a user, imagine currently I have a few 1000 lines of perfectly fine code that uses PCA(n_components) (and other comparable use cases). If tomorrow it's going to start raising warnings to change it to PCA(n_components=n_components) and require me to do maintenance work without good reason, personally I would be unhappy and will complain about it to whatever project did that.

@agramfort explicitly argued for accepting PCA(n_components).

I really think the point made on the mailing list about allowing users to have clear expectations is important. If we can't write down a simple rule it's hard for users to have clear expectations.

Doing some quick stats:

from collections import Counter
from inspect import signature
from sklearn.utils.testing import all_estimators

counts = Counter()

for name, est in all_estimators():
    sig = signature(est)
    if len(sig.parameters):
        first = list(sig.parameters.keys())[0]
        counts[first] += 1

There's 61 different first arguments in our estimators.

Maybe having a white-list of those that we allow would be useful?
Say, 'n_components', 'alpha', 'estimator', 'base_estimator', 'kernel' (this is not for SVC), 'n_clusters', 'n_estimators', 'n_neighbors', 'C', 'steps', 'regressor', 'transformers'?

Though the C is a bit of an outlier and I think having 'store_precision' be positional would not be very useful so I didn't list it. Generally I think for all meta-estimators the first argument should be positional.

Generally I think for all meta-estimators the first argument should be positional.

Agreed.

I prefer narrowing the list down to just clustering, decomposition, and meta estimator parameters: 'n_components', 'estimator', 'base_estimator', 'n_clusters', 'n_neighbors', 'steps', 'regressor', 'transformers'

Hm that's deprecating LogisticRegression(0.01) and RandomForestClassifier(100)`` ... I'm not super opposed but also could see some resistance?

LogisticRegression(0.01) isn't a thing: the first parameter is penalty

A major company recently did a giant github scrape and analyzed sklearn usage. I asked them whether they can share their results.

Hi guys,
I did some preliminary analysis for @jnothman using AST and these are the results for the aggregated data and analysis related to the repo/file.

Let me know if you have any questions. I intend to upload the code (need a bit of cleaning!) I used to run this analysis soon, so you guys can have a look.

Briefly a piece of code downloads the repos from a list of repos (grabbed from the dependents tree or by getting a list of repos using Google BigQuery on the GitHub public dataset - in the latter I run out of free usage credits) and convert the *.ipynb to *.py using nbconvert, then another code runs through all repo files in parallel and search, using AST, for callables on objects imported from all_estimators.
The code does not handle case where the import is of this form: from sklearn.ensemble import RandomForestClassifier as RFC.

@srggrs Thank you for the analysis!

It looks like nr_pos_args is bounded below by 1. Does this mean that all estimators uses at least one positional argument?

Also, nr_pos_args max seems to be 1 for many estimators, which looks pretty odd to me.

It looks like nr_pos_args is bounded below by 1. Does this mean that all estimators uses at least one positional argument?

Because the analysis here is limited to class constructors (next version should not, I think, have this limitation), the first arg is always self, and so the lower bound of 1 makes sense.

I'm happy to have in 0.22 if you still think we can have it in 0.22 @jnothman

@adrinjalali I've added a list of the subpackages we've resolved this for, and those still to go, in the PR description.

Once this is done, and included in the RC, we should heavily advertise the RC to make sure people discover potential issues before the final release. If there are many complaints, we might need to relax some of the most common positional arguments.

Should we leave utils alone?

Should we leave utils alone?

I'll try to open a PR but I would agree there's no strong need to get it in for the release

I'll try to open a PR but I would agree there's no strong need to get it in for the release

Okay, let's see what it looks like. In general, it would be "nice to have" since it would make the library more consistent and promote the usage of * in future util functions.

I think this one is now complete. There may be missing ones, which we can deal with later with delayed deprecations.

Thanks for all your effort to everyone involved. This is a great thing for making the parameters more findable in a year's time.